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
We had interesting brainstorm in context of release process and #9 PR with @murarustefaan and @WitoDelnat. There are multiple approaches and tools to handle this, but at this stage we don't have very clear vision - since we did 0 releases so far and it's difficult to say what will be needed or useful.
Still we know there is a place for improvement. It seems beneficial to decouple containers versioning from chart versioning as describe in #9 (comment) thread:
I'd keep the versions separated. There is little benefit to having them being the same. If you have problems with certificates it can even help to see if the init container changed (meaningfully).
As for the Helm Chart versioning I'm a bit more hesitant. Do we want to publish a new Chart for each Docker Image or leave the image as a variable in the values.yaml and default it to latest (...)
I have not seen a lot of projects linking the Chart and App Versions, they are separated for a reason.
Chart version should change only on Chart modifications, while App Version should change alongside the image version. Here I would link the App Version to the admission controller version (which should be configurable trough values, just in case) while leaving the init container set to latest.
Also decoupling image build/push from release process:
So the flow i had in my mind was more on the lines of:
merges into main will build & push images with the corresponding package.json version, just like we do for the cloud application yet with image tags derived from package.json version.
tag pushes will force chart deployments (or here we can even do both, we can have tags following a naming scheme like chart/v1.1.1 & server/v1.1.1 and do both builds & chart release, it is up to you)
the image tag for the server we can either update manually before pushing a chart tag for releasing, create a pre-commit hook that will modify the images to the package.json version, or set to latest, i'm not yet sure how we could easily do it automatically yet
And:
Or another idea, if you want to keep them together is during build update the version of AppVersion, and during release check if there is already a release with that appVersion in the registry
The text was updated successfully, but these errors were encountered:
We had interesting brainstorm in context of release process and #9 PR with @murarustefaan and @WitoDelnat. There are multiple approaches and tools to handle this, but at this stage we don't have very clear vision - since we did 0 releases so far and it's difficult to say what will be needed or useful.
Still we know there is a place for improvement. It seems beneficial to decouple containers versioning from chart versioning as describe in #9 (comment) thread:
Also decoupling image build/push from release process:
And:
The text was updated successfully, but these errors were encountered: