Managing the gem versions for mailroom, for official releases
GitLab.com deploys mailroom on VMs, we are considering a transition to Kubernetes for this service. On VMs, the mailroom gem is installed as part of the omnibus package which is bundled with rails.
For cloud native, when there is a tagged release, we create tagged set of CNG images, for example https://dev.gitlab.org/gitlab/charts/components/images/pipelines/130881
For mailroom CNG, gem versions are set in the following script https://gitlab.com/gitlab-org/build/CNG/blob/78d2f1f5045a95244a25503a0fa98805e76dd08f/gitlab-mailroom/scripts/install-dependencies#L12-15
where the mailroom gem version looks to be hardcoded in the Dockerfile https://gitlab.com/gitlab-org/build/CNG/blob/78d2f1f5045a95244a25503a0fa98805e76dd08f/gitlab-mailroom/Dockerfile#L6
This version of mailroom is also set in the gitlab source tree https://gitlab.com/gitlab-org/gitlab/blob/2f9fef7895854f4d9f681811e82fca0eee5bb9f1/Gemfile#L414 as well as other gems to run the service, like
charlock_holmes redis redis-namespace
When we build the mailroom image, should we be using the gem version specified in the gitlab source tree for the corresponding tag? Is there a better strategy we can use? The gem versions for mailroom dependencies are hardcoded, should they be passed into this pipeline as well?