Search code examples
gitlabgitlab-ci

Can I make GitLab jobs manual, unless they are run in a Merge Train?


We are trying to create a good merge train setup in our institutional GitLab. Currently, we have a few jobs in our pipeline which run expensive fuzzy tests. These jobs should not run on every push, but they should run before a merge and it should be possible to activate them manually.

Currently these jobs are marked as manual for a generic pipeline.

fuzzy-tests:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: >
        $CI_COMMIT_TAG ||
        $CI_COMMIT_BRANCH == 'main' ||
        $CI_COMMIT_BRANCH == 'release/*' ||
        $PUBLISH_DEV_VERSION
      when: on_success
    - when: manual

They should run automatically as part of a merge train pipeline, because when the merge train is going, we don't want to start the manual job. Is there a way to figure out as part of the rules entry whether a job's context is a Merge Train Pipeline?

If not, is there a good way to ensure that fuzzy-tests is run at least once before each merge, can be run on demand, and is not run on every change of the merge request?


Solution

  • They should run automatically as part of a merge train pipeline [...] Is there a way to figure out as part of the rules entry whether a job's context is a Merge Train Pipeline?

    You can use the CI_MERGE_REQUEST_EVENT_TYPE variable. Per the documentation, this variable contains:

    The event type of the merge request. Can be detached, merged_result or merge_train.

    So, perhaps you setup your job rules, in relevant part, to use this variable like so:

    fuzzy-tests:
      rules:
        - if: $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"
          when: on_success
        # ...
    

    Keep in mind also that, on merge request pipelines, CI_COMMIT_BRANCH won't be present. As noted in the documentation (emphasis added):

    The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines.

    If you need to use a rule with compound clauses that depends on the branch/tag naming while also in a context other than a branch pipeline, you might consider using CI_COMMIT_REF_NAME instead, which is available in more contexts, or more explicitly, CI_MERGE_REQUEST_SOURCE_BRANCH_NAME in the case of merge requests.