Allow triggered pipelines to have compliance framework yaml injected

Summary

!78878 (merged) was merged to address #339463 (closed), by preventing a compliance configuration from replacing a child pipeline by not injecting the compliance configuration if downstream of a bridge pipeline.

This creates another problem, where compliance framework pipeline is not injected into a triggered downstream pipeline, despite that project having a compliance framework enforced. A customer has come across this recently, and was surprised to see that the compliance framework could be circumvented in this way. Please see GitLab Ticket for context (internal).

I tried to reproduce the issue by commenting this line of code and restarting GitLab. From my limited testing, I cannot reproduce #339463 (closed) in version 14.8.6 and above with this code change made. Perhaps the issue where the child pipeline inherits the parent's YAML, and introduces a recursion loop, has been fixed?

Steps to reproduce

Performed on version 14.8.6 self-managed. Local code change is only to illustrate the behaviour.

  1. Create top-level group complianceframework
  2. Create projects projecta, projectb, projectz in the group
  3. Create a compliance-framework.yml in projectz project as per attached yaml
  4. Create a Compliance Framework at the group level. Refer to compliance-framework.yml in projectz project
  5. Apply the Compliance Framework to both projecta and projectb
  6. Create a simple pipeline for projecta as per attached yaml
  7. Create a simple pipeline for projectb as per attached yaml. This contains a trigger for projecta pipeline
  8. Run a pipeline for projecta
  9. Run a pipeline for projectb
  10. Comment this line of code in gitlab/embedded/service/gitlab-rails/ee/lib/gitlab/ci/pipeline/chain/config/content/compliance.rb
  11. Restart GitLab: sudo gitlab-ctl restart
  12. Perform steps 1 - 9 again

Example Project

What is the current bug behavior?

  1. Pipeline for projecta contains Compliance Framework pipeline jobs.
  2. Downstream Pipeline for projecta does not contain Compliance Framework pipeline jobs.
  3. Downstream pipeline for projecta should result in a failed pipeline as per #339463 (closed)

What is the expected correct behavior?

  1. Pipeline for projecta should contain Compliance Framework pipeline jobs, as these should be applied to all pipelines for the project.
  2. Downstream Pipeline for projecta should contain Compliance Framework pipeline jobs, as these should be applied to all pipelines for the project.
  3. Downstream pipeline for projecta should have resulted in a failed pipeline as per #339463 (closed), however the child pipeline contains its own YAML, plus the Compliance Framework pipeline jobs.

Relevant logs and/or screenshots

projectb pipeline triggers projecta pre- local code change. No compliance framework injected as per MR !78878 (merged)

projectb-pipeline-trigger-a-pre-code-change

projectb pipeline trigger projecta post- local code change. Compliance framework yaml injected, AND the downstream pipeline uses its own YAML, not the parent's YAML as per !339463

projectb-pipeline-trigger-a-post-code-change

Project A .gitlab-ci.yml 

stages:
    - pre-compliance
    - post-compliance

projecta-job-one:
    stage: pre-compliance
    script:
        - echo projecta

projecta-job-two:
    stage: post-compliance
    script:
        - echo projecta

Project B .gitlab-ci.yml 

stages:
    - pre-compliance
    - post-compliance

projectb-job-one:
    stage: pre-compliance
    script:
        - echo projectb

projectb-job-two:
    stage: post-compliance
    script:
        - echo projectb

projecta-trigger:
    stage: post-compliance
    trigger:
        project: complianceframework/projecta
        branch: main

Project Z Compliance compliance-framework.yml 

stages:
    - pre-compliance
    - compliance
    - post-compliance

compliance-job:
    stage: compliance
    script:
        - echo "compliance job"

include:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  project: '$CI_PROJECT_PATH'
  file: '$CI_CONFIG_PATH'
  ref: '$CI_COMMIT_REF_NAME' # Must be defined or MR pipelines always use the use default branch

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

  1. Remove the guard clause related to the downstream source bridge https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/ci/project_config/compliance.rb#L11
  2. Add guard clause for child pipeline only
  3. Update/Add relevant test cases.
Edited by Harsimar Sandhu