When a trigger: keyword is used in a regular project that has compliance pipeline feature in use, the downstream config is not triggered.
The bridge job starts a new compliance pipeline that ends up re-running the parent pipeline, and this recurses until the maximum depth error is hit (after 3 attempts)
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Why interested: Why is this important to you? Master/default branch pipeline is executed on adding compliance label and stage even for the branches. When a compliance pipeline has been configured and child pipelines are triggered they hit a recursion when they attempt one.
The child pipeline (produced via a simple trigger of another local file) seems to re-involve the required pipeline config, which then re-includes the parent pipeline which re-triggers a child attempt, and this goes on until the recursion limit is hit. The jobs in the actual child pipeline's config are never executed, almost as if CI_CONFIG_PATH doesn't update to reflect the child pipeline definition.
Current solution for this problem: Solution to this is to use the change added here: #331506 (closed) The customer can now use $CI_COMMIT_REF_NAME variable in the ref: key inside the include statement.
@shoyle1 - The solution mentioned above does not solve the underlying child pipeline problem. Also, this is a bug not a feature request. Tagging @cherryhan@vamsivs
@hchouraria@stkerr This is still a priority for this customer and the workaround solution does not solve the underlying child pipeline problem. Are you aware of another workaround for them to use in the meantime?
@shoyle1 right now we just have the workarounds that we discussed at the last call, such as moving to an include approach or to put the child pipelines in a separate project & trigger them remotely with the API. For future work, we are considering how we would want to properly solve this issue, most likely relying on new variables as a way to drive the conditional logic to switch between the parent or child pipeline.
@mwoolf assigning to you for refinement. I know you are quite heavily loaded with deliverable issues right now, so this refinement is very tentative for whenever you might have time.
@RamKothur I'm sorry, we don't have this scheduled yet so it's not clear what the release date might be. Please keep following notifications on this issue for updates.
Ok, I think this should be fairly simple to fix. We'll need to pass the ref for the pipeline through to ee/lib/gitlab/ci/pipeline/chain/config/content/compliance.rb:16. It seems to work with a hard-coded branch so should solve the issue for MRs too.
Marking this issue as blocked by #332040 (closed). I'm not 100% certain that it is blocking, but the code changes are going to be in very similar areas so it's not sensible to work on this right now until the other issue is closed.
If you're a self-managed customer, you can install GitLab from a nightly build for testing purposes and it'll be available in the 14.8 official release.
My apologies, when I went to create this release post item last month, I got this issue confused with another related issue that is being worked on for %14.9. I am adding this to the release post for %14.9 now so it gets properly announced.