Skip to content

Ensures all CI jobs have consistent push_tags pattern

Balasankar 'Balu' C requested to merge push-consistent-tag into master

What does this MR do?

This MR has two intentions

  1. Make it easier to document how components are tagged
  2. Future proof tagging when gitlab-org/gitlab changes it's default branch name from master to something else while CNG remains on master. Right now, in master branch pipelines of CNG, these components gets tagged with master not from the $CI_COMMIT_REF_SLUG like every other component , but because of coincidence that their versions are also set as "master" in ci_files/variables.yml.

Once this MR is merged, we will be able to document our tagging logic as follows

  1. 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.
  2. 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).
  3. On feature/stable branch and auto-deploy tag pipelines, components gets tagged with branch/tag slug only.
  4. 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

Merge request reports