When instantiating a Nix package via Bazel, the package set is called
with an empty map as the argument. From the Nix REPL or the dispatch
script, however, the package set is called without arguments.
This change adds a catch-all optional argument in the package set
which ensures that both use-cases are supported (similar to what
nixpkgs itself does).
Initial version of tool provider via Nix. This requires two separate
steps for adding a new tool:
1. New symlink in tools/bin to point at the dispatch script.
2. Mapping of tool to Nix package set attribute in dispatch script.
This updates some old code that makes assumptions via pattern matching
to instead make assumptions via a Prelude function.
This is known to be safe as it has been running fine for almost a
decade now, but the recent MonadFail changes broke the build.
Note that this does not actually build right now because Elm has done
a thing again to break the universe and it requires massive changes to
the application to make it work again.
An advantage of this method over the previous one is that any edits to
the ConfigMap yaml file will also trigger a rolling update.
It also keeps knowledge of what the ConfigMap contains inside its yaml
file instead of the Deployment needing to know which variables to hash.
Similar to insertFile, but runs the templating against the file before
inserting.
This is useful for sharing common config between yaml files, e.g. volume
mounts in a deployment.yaml and cronjob.yaml, and it's useful to be able
to use the `configHash` annotation pattern with a templated
configmap.yaml
Changes in the Go build environment for Nix have caused the parallel
vetting to run in a subshell which does not have the required function
definitions.
This commit fixes the error by not running vet in parallel (there's no
point to that anyways as the project is tiny).
Instead of relying on the external httpbin instance which is
occasionally wonky, use Docker to spin up a local instance in Travis
CI when testing.
This fixes#1.
When uploading larger amounts of data, cURL will call the read
callback incrementally multiple times to receive all the expected
data.
Previously if the size of the data to upload exceeded the size of the
initial buffer provided by cURL, the write (and thus the request)
would fail.
This changes the logic to write the data in chunks of a size that are
acceptable to cURL.