-
Notifications
You must be signed in to change notification settings - Fork 4
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
ADR for require no maintenance to keep bootstrapping cli up to date #142
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be good to have some other alternatives considered like the one suggested in review
|
||
## Context | ||
|
||
Currently, CLI bootstrapping creates and manages WGE values [here](https://github.com/weaveworks/weave-gitops-enterprise/blob/d27d52cf1053d194a40e7652a570d810db552613/pkg/bootstrap/steps/install_wge.go#L49-L124). This means any update / breaking change happens to WGE values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as suggested during standup, i think it is worth considering other options. for example here there is a couple
a) refactoring the install wge
step to the shape of terraform where we dont manage values. Something like consuming a helmrelease manifest as stated here. To generate and publish that manifest could be done as part of the release process (we have to do it as part of weaveworks/weave-gitops-enterprise#2213 )
b) how flux does it where flux v2.1.0 can only bootstrap flux for v2.1.0 so in this case refactoring install wge to just install the version that the cli belongs to. for example gitops-ee v0.38 only install v0.38, etc ...
see artifacts in https://github.com/fluxcd/flux2/releases/tag/v2.2.0 and https://github.com/fluxcd/flux2/blob/00c6ac81b9938e80a79c5b625b06cfb4f220c3db/pkg/manifestgen/install/manifests.go#L37
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean like publishing a oci repo with the different controller manifests, right? It sounds interesting over pull the indenpedent manifests. i also think that could also provide a more flexible / maintainable approach to install over existing helm dependency one
ADR with suggested option for weaveworks/weave-gitops-enterprise#3706