Problem to solve
Recently after upgrading to v17.2.2-ee our Components build/release pipeline stopped accepting our release tags and began munging it into a major.minor.bug component of the semantic versioning spec. However the docs specify that it should be valid semantic versioning, which we use. And I’ve validated our recent tags against Online Semver checker as being compliant with semantic versioning. Another thing I noted is the docs seem to indicate that it may be a branch or a tag… Assuming we created a branch that it didn’t like, would it use it? Additionally I’m not sure how that’s even possible as it this whole thing pulls from a release which points to a tag not a branch! So what’s up with the docs on this CI/CD components | GitLab
Observed behavior
What we are seeing is that the release accepts our tag scheme, the tag scheme is valid semantic, the tag is linked to the release correctly. But the component now shows the tag as 1.6.0 for the tag like 1.6.0+build.mr-121.comp.20. Obviously we did not create that tag so we get dead links, no README.md displayed for the component and the include include statements for detected components point to @1.6.0 which doesn’t exist. Interestingly the components are detected and listed on the components tab correctly which suggests to me that somewhere in the component publishing logic it is still loading the correct tag REF and finds the components on our tag REF.
When publishing a component for release 1.6.0+build.mr-121.comp.20 it appears like the prefix of 1.6.0 is being scraped off the tag name and used in place of the releases tag. However, since our release and tag are of the semantic form 1.6.0+build.mr-121.comp.20 it seems like something is overriding out selected tag name for it’s own purposes 
Side note on why we use the versioning scheme we chose
TLDR;
We selected a tag scheme that help us quickly determine exactly which software version, build and Component schema is in use on any given external teams pipeline and which OCI image tag is used and which software version is used. We then can see via the tag, job log output and local client logs exactly what the release represents for the tools run.
Reasoning behind using our tagging scheme, our version tags track the following for these reasons:
Software release: 1.6.0
Build id: build.mr-121 (correlates to a tag mr-121 allowing us to easily track builds back to the MR)
Component version: comp.20 (allows us to understand when we’ve updated the component ci code)
Each part of our selected tag scheme is important in tracking how the software will/won’t behave in the both the pipeline and locally. We share this out to our users and it’s easy to know exactly which software version, image and component they are using in their pipeline or locally at a glance.
The thing to note here is that there are valid reasons where the build might be bumped with no software change version change e.g. 1.6.0 build.mr-122 because the image Dockerfile needed a security update or something. It is also possible to need a change to the component CI logic which might look like 1.6.0+build.mr-122.comp.21 which only indicates that the component needed a bump.
Our CI pipeline builds and tags a new image for every MR so that every MR must past the tests for the current code and config changes. This is because you could have changes to tests, dependencies or build/compile logic that aren’t a change in the source code for the underlying application version. Even something as little as swapping base image tags then yields a full and complete Docker build, test and security scan for every MR.
Steps to reproduce
Use a more complex semantic tagging scheme like 1.6.0+build.1
Possible solutions
-
One temporary solution is to also create another rolling tag in or “retag” job that tags against main, but creates a rolling tag to just the 1.x.x prefix that seems to “work”. However this not an ideal solution.
-
This is where I’m hoping for someone to point out the real reason why our two projects suddenly stopped publishing Components correctly.
Configuration
complex gitlabci.yml with multiple included pipelines with separate triggered pipelines for build, test, component integration test and release pipelines for both MRs and merges to main.
Versions
- Self-managed v17.2.2-ee
- Self-hosted Runners