How can I prevent jobs from running based on the files changed compared with master?

user_493729 0
Viewed 281

I have some gitlab jobs in my pipleline which are slow and I'd like to prevent them from running when the changes will not affect the job's outcome.

This is what I have tried:

run_tests:
  stage: checks
  script:
    - cargo test
  except:
    - master
    - tags
  only:
    changes:
      - "**/*.rs"
      - "**/Cargo.toml"
      - "**/Cargo.lock"

This sort of works. If a merge request has multiple commits, this job will not run on any of the commits after the first one, unless a Rust source file has changed.

But the job will still always run on the first commit of the branch, even if there are no changes to Rust source files between this branch and master. Even worse, if the tests fail on the first commit, subsequent commits might skip the tests so broken code could get merged.

How can I change this filter so that the diff is done against the target branch of the merge request?

gitlab gitlab-ci
1 Answers

Hidden quite deep in the documentation for only: changes, there is this snippet:

Without pipelines for merge requests, pipelines run on branches or tags that don’t have an explicit association with a merge request. In this case, a previous SHA is used to calculate the diff, which equivalent to git diff HEAD~. This could result in some unexpected behavior, including:

  • When pushing a new branch or a new tag to GitLab, the policy always evaluates to true.
  • When pushing a new commit, the changed files are calculated using the previous commit as the base SHA

Which is the scenario you are currently experiencing, where the job always runs on the first commit of the new branch.

For this to work as you want, I believe you need to add only: merge_requests, however this would require changing your entire pipeline workflow to integrate only: merge_requests to your pipeline.

From the documentation:

With pipelines for merge requests, it’s possible to define a job to be created based on files modified in a merge request.

In order to deduce the correct base SHA of the source branch, we recommend combining this keyword with only: [merge_requests]. This way, file differences are correctly calculated from any further commits, thus all changes in the merge requests are properly tested in pipelines.

Various issues from GitLab:

user_40474720
Related