Ensures all CI jobs have consistent push_tags pattern
What does this MR do?
This MR has two intentions
- Make it easier to document how components are tagged
- Future proof tagging when
gitlab-org/gitlab
changes it's default branch name frommaster
to something else while CNG remains onmaster
. Right now, inmaster
branch pipelines of CNG, these components gets tagged withmaster
not from the$CI_COMMIT_REF_SLUG
like every other component , but because of coincidence that their versions are also set as"master"
inci_files/variables.yml
.
Once this MR is merged, we will be able to document our tagging logic as follows
- Every component gets tagged with a unique identifier, called
CONTAINER_VERSION
that is computed based on multiple factors like build sources (Dockerfile and related files) and dependencies. This identifier is essentially used to decide whether to build an image or not (i.e, has anything warranting a rebuild has happened). This identifier value is same across branches/tags, provided the factors remain same, thus allowing us to skip unnecessary rebuilds. - On default branch and regular tag pipelines, components gets tagged with (i) the branch's/tag's slug, and (ii) their individual versions (with
-ee
suffix stripped for Rails components, if present). - On feature/stable branch and auto-deploy tag pipelines, components gets tagged with branch/tag slug only.
- For UBI/FIPS builds, these tags (except
CONTAINER_VERSION
) gets a-ubi8
or-fips
suffix.
Disadvantage: Right now, this makes the following push_tags
no-op/redundant. However, this is already the case with all other components on feature branches. For example, we can see postgresql
being attempted to be pushed twice with the same slug in this MR's pipeline job - https://gitlab.com/gitlab-org/build/CNG/-/jobs/3227918453. This shouldn't cause much of an impact on the pipeline duration since all the layers already exist.
Related issues
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion
Required
-
Merge Request Title, and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated -
Integration tests added to GitLab QA -
The impact any change in container size has should be evaluated
Edited by Robert Marshall