docs: add proposal for image versioning - #1281
Conversation
Signed-off-by: Ryan Edgell <redgell@us.ibm.com>
|
|
||
| Four steps, each its own PR, each safe on its own: | ||
|
|
||
| 1. **Close the existing gaps.** Add the missing translate and extract image build workflows and scanner entries, copying the pattern the other services already use. |
There was a problem hiding this comment.
I'll remove this part from the proposal.
mkumatag
left a comment
mkumatag
left a comment
There was a problem hiding this comment.
this looks promising, have a minor comment otherwise LGTM from my side..
|
|
||
| **Release branches get their own tag lineage.** Both `main` and `release-*` branches publish to the same registry, and each branch carries its own snapshot of `versions.yaml`, so without special handling they'd eventually hand out the same tag to two different builds. Concretely: we cut `release-0.2` while chatbot-service is at `v0.0.26`, main keeps moving and publishes `v0.0.27`, then a hotfix lands on the release branch and its CI (still reading `v0.0.26` from its own `versions.yaml`) also computes `v0.0.27`. Registry tags are just mutable pointers, so whichever push comes second silently overwrites the first, and "v0.0.27" now means different code depending on when you pulled it. That's a problem anywhere, but especially for us since we sign images by tag. | ||
|
|
||
| To keep the sequences from ever meeting, the first bump on a release branch appends the branch name and starts a counter (`v0.0.26` → `v0.0.26-release-0.2.1`), and later bumps on that branch just increment the counter (`.2`, `.3`, ...). Main never produces suffixed tags, so collisions are impossible, and the tag becomes self-describing: `v0.0.26-release-0.2.3` is the third fix on `release-0.2`, which forked while chatbot-service was at `v0.0.26`. Signing and promotion don't care about the format, though we should double-check nothing in the Jenkins pipeline assumes tags look exactly like `vX.Y.Z` before the first release-branch bump. |
There was a problem hiding this comment.
may be we can consider using v0.0.27-x versions for the release branches
There was a problem hiding this comment.
I went with this format to make it descriptive at a glance, but sure, this could be changed if you prefer.
Adding the branch also ensures there is absolutely never any tag naming collision. Using this other format is likely ok, but it will not guarantee collision is impossible like it is when including the branch name.
There was a problem hiding this comment.
Our versions are not 100% perfect. However, that is a separate topic for discussion and, I believe, out of scope for this document. We can brainstorm it further and decide on the right approach separately. CC: @adarshagrawal38
|
|
||
| ## What we'd change | ||
|
|
||
| The short version: **versions move out of PRs entirely.** You merge code, CI figures out what changed, builds and publishes the image with the next version number, and commits the bump itself. Nobody edits a version string by hand for normal day-to-day work. |
There was a problem hiding this comment.
Dont we need to give permissions to github bot to be able to directly merge to main branch or is it safe for it to have permissions to only raise a PR and we merge it to be safe?
There was a problem hiding this comment.
This is specifically mentioned near the end of the proposal.
The reason I decided on this is to make it completely automatic, not have a trail of additional PRs that have to be manually merged every time anything else is merged.
| registry: icr.io/ai-services-cicd | ||
| images: | ||
| chatbot-service: | ||
| tag: v0.0.25 | ||
| source: [services/chatbot, services/common] | ||
| chatbot-ui: | ||
| tag: v0.0.50 | ||
| source: [ui/chatbot] | ||
| digitize-service: | ||
| tag: v0.0.43 | ||
| source: [services/digitize, services/common] |
dharaneeshvrd
left a comment
dharaneeshvrd
left a comment
There was a problem hiding this comment.
Overall lgtm
Can we please design the bump workflow to also make changes in rag-dev template's values.yaml as well? since we are using those legacy templates to share the machine for development which is really easy for us to plug and play individual services which is not the case in catalog way of deployment.
If we don't do this, then those templates will become unusable.
With this proposal, every values.yaml file would update when the version bump workflow runs. Is that what you mean here, or are you referring to a specific change about that template file? |
|
Ok, if it updates every values.yaml, then we are good. I am looking at this values.yaml updated whenever there is a service version bump. |
6 participants
No description provided.