ADR for require no maintenance to keep bootstrapping cli up to date - #142
ADR for require no maintenance to keep bootstrapping cli up to date#142waleedhammam wants to merge 2 commits into
Conversation
enekofb
left a comment
enekofb
left a comment
There was a problem hiding this comment.
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.
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.
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
2 participants
ADR with suggested option for weaveworks/weave-gitops-enterprise#3706