- Semantic versioning is enabled by default
- Ensure the cd handles the new semantic versioned tags
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| In Progress | RThomas-WMF | T358575 Kubernetes(k8s) platform for Enterprise Applications | |||
| Open | None | T384574 [APP: Objective 3 Term 3.3. - WME OKR TBD- Q1-Q2 FY 25-26]- Gitlab on k8s | |||
| In Progress | This.chris.corriere | T410902 Semantic Versioning of enterprise images |
Event Timeline
per slack conversation this will likely need to be rescoped to include internal dependencies like schema. If an enterprise image needs to be rebuilt based on a semver tag it can be "officially validated" unless the dependencies are pinned to a version as well and included in an SBOM.
admin service is a safe proof of concept candidate for semver. It's relatively small so low risk for an initial example. I can test this in a project like pipeline-test or use pipeline-test for the PoC if it's more convenient.
Are we pushing to snapshot while in non-prod?
Should there be an RC that's migrated from non-prod to prod when merging to main, or are we rebuilding the artifact?
per slack convo: The scope here is to ensure the dev and the main branch builds have semantic versioning tags and the CD environment is able to pull the tagged images automatically via argocd. Currently, we pull only latest tags. Stretched goal for this epic will also be looking into generating automated changelogs
we're exploring some trade-offs between the gitlab/cdtools approach from my initial PoC with a python library. I tested the library some this week and stopped at an authentication issue around PATs for git access.
My next steps are to document the trade-offs in the design doc Renil started, then debug the PAT auth issues to complete the alternate PoC if the team decides to A/B test them.