Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab FOSS
GitLab FOSS
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 1
    • Merge requests 1
  • Requirements
    • Requirements
    • List
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #79661

Closed (moved)
Open
Created Feb 19, 2021 by Benjamin Sproule@benjamin.sproule.bmi

Merge Request pipeline doesn't allow changes

Summary

When setting up pipelines to only run for merge requests and to filter by certain file/folder changes, the jobs aren't always run.

Steps to reproduce

We have a series of jobs in a monorepo that we only want to run if certain projects have changed. For example, we have the following folder structure:

/applications

  • /application-a -- /.gitlab-ci.yml
  • /application-b -- /.gitlab-ci.yml
  • /application-c -- /.gitlab-ci.yml /components
  • /component-a
  • /component-b
  • /component-c
  • /jest
  • /.gitlab-ci.yml /.gitlab-ci.yml

The root gitlab-ci.yml includes all the others, and each projects gitlab-ci.yml adds the jobs specifically for that project. Some jobs always run:

eslint-sast:
  rules:
    - if: "$CI_COMMIT_TAG || $CI_MERGE_REQUEST_ID || $CI_COMMIT_BRANCH == 'master'"

nodejs-scan-sast:
  rules:
    - if: "$CI_COMMIT_TAG || $CI_MERGE_REQUEST_ID || $CI_COMMIT_BRANCH == 'master'"

install:
  stage: install
  rules:
    - if: "$CI_COMMIT_TAG || $CI_MERGE_REQUEST_ID || $CI_COMMIT_BRANCH == 'master'"
  before_script:
    - yarn config set cache-folder ~/.yarn
  script:
    - yarn install --frozen-lockfile
  cache:
    key:
      files:
        - yarn.lock
    untracked: true
    paths:
      - "**/node_modules"
      - "~/.yarn"
    policy: pull-push
  interruptible: true

license_finder:
  stage: audit
  rules:
    - if: "$CI_COMMIT_TAG || $CI_MERGE_REQUEST_ID || $CI_COMMIT_BRANCH == 'master'"
  needs: [install]
  image: licensefinder/license_finder:latest
  before_script:
    - source ~/.bash_profile
    - yarn config set cache-folder ~/.yarn
    - curl -sL https://deb.nodesource.com/setup_12.x | bash - && apt-get -y install nodejs
  script:
    - license_finder report --format html > license_finder_output.html
  artifacts:
    paths:
      - license_finder_output.html
  interruptible: true

But others will only run if the projects specific gitlab-ci.yml changes:

# /applications/application-a/.gitlab-ci.yml
test_application_a:
  stage: test
  rules:
    - if: "$CI_COMMIT_TAG || $CI_MERGE_REQUEST_ID || $CI_COMMIT_BRANCH == 'master'"
      changes:
        - applications/application-a/**
        - jest/**
  needs: [install]
  before_script:
    - yarn config set cache-folder ~/.yarn
  script:
    - yarn workspace @company/application-a coverage:jest
  interruptible: true

If I change $CI_MERGE_REQUEST_ID to $CI_OPEN_MERGE_REQUESTS in the rules if, it will trigger 2 pipelines for each commit. The first has all the correct jobs running and is a branch pipeline, but the second is a merge request pipeline and will not run all the correct jobs.

What is the current bug behavior?

Expected jobs aren't run.

What is the expected correct behavior?

Jobs run when a project's files are changed.

Results of GitLab environment info

This is all on gitlab.com.

Edited Feb 19, 2021 by Benjamin Sproule
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None