Skip to content

De-duplicate cache updating jobs in omnibus-gitlab-mirror

As part of fixing #3988 (closed), the main change we made was

  1. Builds triggered from gitlab-org/gitlab MRs will use GITLAB identifier in the cache key
    1. Cache used by these builds will be updated by update-trigger-package-cache job in the pipeline caused by the 2-hourly schedule in gitlab-org/gitlab (named [2-hourly] Repo caching, Review Apps cleanup, Caches update)
  2. Builds triggered from omnibus-gitlab MRs and nightly pipelines will do the following
    1. If EE builds, use EE identifier in cache key
    2. If CE builds, use CE identifier in cache key
    3. Cache used by these builds will be updated by update-trigger-package-cache job in the nightly pipelines - one for CE and one for EE.

The problem is that, the pipeline caused downstream in omnibus-gitlab-mirror by that 2-hourly schedule in gitlab-org/gitlab looks like this

image

The update-trigger-package-cache job and Trigger:package job is doing very similar action - building a GitLab package. What differs is that, update-trigger-package-cache won't use any cache, but pushes the build result to cache while Trigger:package pulls the cache but won't push it back. This is wastage of resources. The former also doesn't do other actions like renaming the package file or exposing artifacts that could be used by Docker builds or anything (so that we could replace the Trigger:package job in that pipeline with it)

Proposal 1
  1. Make update-trigger-package-cache do everything Trigger:package does, with the exception of whether it pulls or pushes cache.
  2. Make other Trigger:* declare an optional need on update-trigger-package-cache so that we can have only it in the 2-hourly pipeline

The problems with this approach are

  1. The pipeline looks ugly. It will be

    (fetch-assets | generate-facts | update-trigger-cache) ====> (Trigger:docker) ====> (Trigger:gitlab-docker | Trigger:RAT | Trigger:package_size_check) ====> (Trigger:letsencrypt-test | Trigger:qa-test)

    Here, update-trigger-cache will do the job of Trigger:package, but it is definitely not intuitive to someone who doesn't know why.

  2. If Engineering Productivity or Quality teams are measuring the pipeline duration of this (the 2-hourly one) scheduled pipeline, they will notice that it has now suddenly gone up.

Proposal 2
  1. Have another scheduled pipeline in gitlab-org/gitlab that is dedicated just to update omnibus-gitlab cache used by gitlab-org/gitlab MRs. (This has to be initiated from a gitlab-org/gitlab schedule because if it is started from omnibus-gitlab, the cache will have wrong versions of GitLab components because the difference in *_VERSION files between gitlab-org/gitlab and omnibus-gitlab.)

Personally, I prefer Proposal 2. Have a new schedule, maybe twice a day whose only job is to tell omnibus-gitlab-mirror to update the GITLAB cache.