workflow proposal #41
Conversation
| id: bump-version | ||
| with: | ||
| github_token: ${{ secrets.GH_TOKEN }} | ||
| default_bump: false |
There was a problem hiding this comment.
The container image would be changing and I don't think we want to overwrite existing image versions, why not generate a new patch version on each push to master?
This way we can stop manually bumping the version in the dockerfile and let Github handle the versionning.
| default_bump: false | |
| default_bump: patch |
or just remove default_bump altogether since it's the default value
There was a problem hiding this comment.
Since every PR will need validation and approval, I think it's a good idea to keep control over the version increase and only bump the image if strictly necessary.
In my mind, a change in the README cannot be considered a version bump, or a typo in a description.
We could add a check, like "if the new tag is undefined, don't run the build job" but rebuilding and pushing the image won't affect the existing one.
Adding a variable in the helm chart is, as the image will be different, a new tag must be generated and a new image will be built and pushed.
|
Fixes #38 Adding this so it auto-closes the BR on merge. |
Co-authored-by: InputObject2 <[email protected]>
Based on recent suggestions by @InputObject2 there's the proposal for a workflow to create, manage and build images for each release.