* Add first install test
* Fix style
* Split the test into spanner and bigtable
* Correct indentation
* Add other distros, shared lib test, and kokoro configs
* Fix style
Specifying a local repository from a Nix file is expected to be
referencing an external nixpkgs source.
However, in this monorepo setup the root of the repository itself is
the Nix package set and a workaround in the `external` folder is
required to import it into Bazel.
This uses the Nix infrastructure's Haskell setup to create a GHC
derivation that comes with all required Haskell packages, fetched &
built via Nix.
Downstream packages that want to make use of Haskell dependencies need
them to be added to this list.
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
