Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persist jsonnet-bundler Lock File #216

Open
srueg opened this issue Oct 13, 2020 · 1 comment
Open

Persist jsonnet-bundler Lock File #216

srueg opened this issue Oct 13, 2020 · 1 comment
Labels
enhancement New feature or request RFC Request for Comments

Comments

@srueg
Copy link
Contributor

srueg commented Oct 13, 2020

Context

Currently the jsonnetfile.lock.json file is recreated on every catalog compile run and uses the most recent versions referenced in all jsonnetfile.json dependencies.
This leads to changing cluster catalogs without changing any of the inputs (components, inventory and facts).
While we can make sure to reference dependencies by immutable versions (i.e. git SHAs) we can't control sub-dependencies (e.g. of kube-prometheus).
The lock file should be persisted in some way so repeatable catalog compiles are possible.

@srueg srueg added the enhancement New feature or request label Oct 13, 2020
@srueg
Copy link
Contributor Author

srueg commented Oct 13, 2020

One approach would be to compile each component as a separate Kapitan target with it's own Jsonnet dependencies. This would allow for each component to commit it's lock file in git and additionally for different components to use different versions of dependencies. This would require a mayor refactor of how the catalog is compiled. It would additionally improve compile times since different targets can be compiled in parallel.

Another approach would be to persist the lock file for the whole cluster in some way (e.g. lieutenant cluster object, tenant git repo, etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request RFC Request for Comments
Projects
None yet
Development

No branches or pull requests

1 participant