Unsetting mirror_trigger_builds does not take effect

Summary

The bug does not enforce mirror_trigger_builds setting will always start pipeline builds. This bug affects GitLab.com and probably every version since the introduction of the mirror_trigger_builds setting.

Steps to reproduce

  1. Create a public "upstream" a project with a .gitlab-ci.yml file (the project can also be private, but then you need to export credentials for the downstream). A trivial file is something like: 
    job:
  script: echo 0
  when: manual
  2. Create a blank "downstream" project and configure it as a pull mirror of the "upstream" project (Settings > Repository> Mirroring repositories > Add new), with the following settings:
    • Mirror direction: Pull
    • Overwrite diverged branches: True
    • Trigger pipelines for mirror updates: False
  3. In the upstream repository, amend the HEAD commit (git commit --amend) and force push (git push --force)
  4. Wait for the mirror to update, or manually trigger an update in Settings > Repository> Mirroring repositories

Note: Force pushing is the most reliable way to reproduce the problem, but we have confirmed examples of the issue occurring without force pushes being involved. We do not yet understand the mechanism for those.

What is the current bug behavior?

A pipeline is created in the downstream project

What is the expected correct behaviour?

No pipeline should be created in the downstream project

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by Hordur Freyr Yngvason