Commit Graph

11 Commits

Author SHA1 Message Date
Gabriel Gonzalez
9a1f76be55 Actually build all releases
This entails some other changes:

* Disable older releases, which don't have the same OpenAPI spec as newer ones
  do

* Add some `dhall-kubernetes-generator` fixes to handle weird behavior for
  certain versions
2020-01-10 20:42:19 -08:00
Gabriel Gonzalez
2e3bbcdc6b Groundwork for supporting multiple releases
Related to https://github.com/dhall-lang/dhall-kubernetes/issues/75

This generalizes the machinery for fetching the Kubernetes OpenAPI spec to
support fetching multiple versions.  In particular, the Kubernetes version
is no longer tied to the version of Nixpkgs that we use.

We still only build generate Dhall types for version 1.16, but in a
subsequent change we can start mass-generating support for multiple
Dhall packages (one per Kubernetes version)
2020-01-10 09:27:06 -08:00
Gabriel Gonzalez
1c6397ccde
Improve coverage for ./scripts/generate.sh (#100)
`./scripts/generate.sh` will now also auto-update the
`./examples/*.dhall` files and `./package.dhall`, too
2020-01-07 18:29:56 -08:00
Greg Ziegan
7af2ab5345 Prefer "schema" syntax for examples (#93)
* Also update to the latest version of `dhall`
* Also fix `./scripts/generate.sh` to generate the `schemas*` files
2019-11-23 16:53:03 -08:00
Fabrizio Ferrai
4ad58156b7
Update to Kubernetes 1.14.3 (#72) 2019-07-30 10:25:00 +03:00
Fabrizio Ferrai
805b432df2
API v2 (#57)
This ports the conversion script from Python to Haskell (fix #7)

The main reasons for this port are that:
- the Python script was really hard to maintain for reasons like 
  "converting from Swagger to Dhall is interleaved with string formatting"
- in Haskell we can use the dhall library to generate always syntactically 
  correct Dhall AST. It's also much easier to keep an eye on correctness, 
  because types and pattern matching. It also forces us to deal with things
  like cyclic imports from the get go.

Things happening here:
- remove the `api` folder, removing the difference between "raw api" and "nice api"
- move defaults from `default` to `defaults` folder, as it is in `dhall-nethack`
- transition to the new syntax for `Optional` (fix #49)
- add `types.dhall` and `defaults.dhall`, so that one can now easily "pin a version"
  by just importing these two records at a specific commit/tag. They also make it really
  easy to access objects, e.g.
  `let types = https://raw.githubusercontent... sha256:... in types.Deployment`
- also add typesUnion.dhall (fix #54), so one is able to send to Kubernetes different
  objects in the same stream. This is also documented in the README
- defaults are resolved recursively (fix #46): if there's an import of a "nullable" record,
  then it's not marked as Optional, making merging objects much easier
- default objects are not lambdas anymore, and instead they just don't include the required
  fields (that is, the ones that are not nullable records), as suggested in dhall-lang/dhall-lang#382
- for objects that are simple types we used to generate a simple lambda
  `\(a : Text) -> a` as a default, now we just don't generate a default (e.g. see
  `io.k8s.apimachinery.pkg.apis.meta.v1.Time`)
- autoformat all generated Dhall code
- remove cyclic imports (fix #47)
- update to dhall-1.22 and dhall-json-1.2.8
2019-05-01 19:13:18 +03:00
Arian van Putten
8d295ecedc
Nixify the build (#55)
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
2019-03-30 11:05:29 +01:00
Fabrizio Ferrai
f860c4e2a4
Upgrade to Kubernetes 0.13.4 (#53) 2019-03-25 12:32:48 +02:00
Fabrizio Ferrai
ad3eff2c7e Unskip tests for some now-passing generated files 2018-11-12 19:20:58 +01:00
Fabrizio Ferrai
f8be1d55bc
Add high level API (#34)
This adds a high level API (+ tests) for:
- Deployment.v1
- Service.v1
2018-09-13 13:33:48 +03:00
Thomas Scholtes
4a7f02cd0d Extract and check examples (#27)
* 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.
2018-08-03 16:24:32 +02:00