You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.).
Context
Currently the
jsonnetfile.lock.json
file is recreated on every catalog compile run and uses the most recent versions referenced in alljsonnetfile.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.
The text was updated successfully, but these errors were encountered: