This makes our build reproducible and consistent
* Disables dhall tests. They don't build in sandbox mode because they require network access
* Moves all scripts to ./scripts folder for consistency
* Moves all nix files to ./nix folder for consistency, except for release.nix which Hydra needs
* Changes convert.py to take the K8s swagger spec as an argument
* Get k8s swagger spec from nixpkgs
* Get dhall prelude from nixpkgs
* added an ./scripts/update-nixpkgs.sh script to easily update to a new version of nixpkgs
* We move all the example code from the readme to the `examples` folder.
* We provide a `scripts/build-readme.sh` script that inlines referenced
examples in `README.md.in` and outputs `README.md`. The script also
verifies that the output readme is the same as in version control.
* We provide a `scripts/build-examples.py` script that builds the Yaml
output for all examples. The script also verifies that the generated
Yaml files are the same as in version control.
As part of this I created a new files `./nixpkgs` that obtains a
specific version of the nixpkgs repo. This code was previously spread
between `release.nix` and `fetchNixpkgs.nix`. I also removed the Nix
1.11 code to simplify things. If we need Nix 1.11 support we can add it
again.
* We add the `glibcLocales` dependency to the somke test. This makes the
`en_US.UTF-8` locale available which is required for `dhall` to work
correctly.
* We also extract `check-sources.py` again so it can be run standalone.
`bash` and `dhall` which are required by the script are still
available when building it with nix.
We improve the convert code by rewriting the `get_typ`. It is now more
general and properly recurses on records and lists. This also surfaced a
bug where definition aliases did not generate correct code.
The `kind` and `apiVersion` properties of a Kubernetes resource are
already implicitly determined by the resource. We adjust the default
functions so that they do not require the `kind` and `apiVersion`
parameters for resources.
We obtain the implied values by inspecting the
`x-kubernetes-group-version-kind` key from the OpenAPI schema for that
resource. The [Kubernetes OpenAPI Spec Readme][1] explains how these
values determine the resource values.
[1]: https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/README.md#x-kubernetes-group-version-kind
