CNG: Fix release tagging for non-gitlab versions to still allow versioned dockerfiles
Summary
Status as of March 2023
All the CNG images are now being versioned with the GitLab version, but some ares of the chart still need to be updated to use this version.
Necessary to fix issues
-
mailroom
Also update these currently handled by deps updates, we can remove the dependency update tracking for these at the same time.
-
gitlab-exporter -
registy
There are others that have their own versions as well, but are currently being handled by release tools, and have frequent releases so don't run into this problem as often. kas
, gitlab-shell
. We could consider logging a followup issue to revisit these. (As these were handled by release-tools, these need a some additional discussion with their stakeholders)
Original Description
Our CNG images have a few images that do not get tagged with the gitlab tag, but rather their own version tag. Examples include mailroom, kubectl. These tags often only reflect the version of the service within, and don't indicate a revision of their dockerfile. This becomes problematic when a backported release pipeline runs, but has the same service version, but different dockerfile, than the latest release.
This happened recently with mailroom:
- The tag was 0.9.1
- We updated the dockerfile to change how the process was started
- The changes was pushed in master as the 0.9.1 tag
- A stable build of 12-4-stable ran without the change
- The older image was pushed as the 0.9.1 tag
For our regular gitlab images, (rails, unicorn, sidekiq) we have decided these will be versioned with their gitlab version. (Which is the tagging we use on the CNG repo). So in order to get a new rails image, a new gitlab patch needs to be released, the dockerfile is not version seperately. This is because the intent is for the dockerfile to eventually be moved in the gitlab repo, and versioned alongside it. This same process would only work for the images like mailroom if we tagged it with the gitlab version as well.