Rules with trigger create an empty pipeline / Workflow rules ignore changes

We run gitlab 14.0.5 and I wanted to use some of the more recent features with our mono repo. What I set up so far is:

---
include:
  - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'

build-proj1:
  stage: build
  trigger:
    include: applications/proj1/gitlab-ci-pipeline.yml
    strategy: depend
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
      - applications/proj1/**/*
#  only:
#    variables:
#      - $CI_COMMIT_TAG == null
#      - $CI_COMMIT_TAG =~ /^proj1@.*$/
#    refs:
#      - merge_requests
#      - branches
#      - tags
#    changes:
#      - applications/proj1/**/*

build-proj2:
  stage: build
  trigger:
    include: applications/proj2/gitlab-ci-pipeline.yml
    strategy: depend
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - applications/proj2/**/*

#  only:
#    variables:
#      - $CI_COMMIT_TAG == null
#      - $CI_COMMIT_TAG =~ /^proj2@.*$/
#    refs:
#      - merge_requests
#      - branches
#      - tags
#    changes:
#    - applications/proj2/**/*

With this, any change to the merge requests triggers both child pipelines, which is not the desired outcome.

When I leave out the include, the same code creates empty child pipelines, which fail because no job gets created.

If I replace rules with only as seen in the commented out sections, it works as intended without variables but as soon as I add the variables section, again all pipelines are started, probably because only reacts on any match.

So I really would like to mix rules with triggers and not fail the child pipelines whenever no change has been done in the listed directories.

Am I doing wrong or is the described behaviour a bug in Gitlab-CI?

As it turns out (or seems),

job:
  rules:
    - changes:
         - somefile

matches for all files changed in the merge request, not only the last commit. If this is true, the documentation really should state this. Can anybody confirm please?

Also there is potential for bugs with:

  • create a new branch and mr from broken build (changes 0)
  • fix the build (changes 1) → Triggers pipeline
  • revert the fix (changes 0) → Doesn’t trigger new pipeline
  • merge back (pipeline succeeded while the code is broken again)
1 Like