Backend: Allow for indicating if a DAG job should block on another manual job, separate from `allow_failure`
Problem to solve
Whether a pipeline is allowed to fail is a different decision from whether it is blocking for downstream jobs (i.e., that they should be prevented from running if this job didn't finish yet), but currently DAG (and normal) jobs block on an allow_failure: false
job but not on an allow_failure: true
job. This sort of makes sense with stage processing, but for DAG jobs you want more control over this. As of right now, you can not have a job that is allow_failure: true
but that a job that needs
it will wait for. This would make it possible to say "If this job is running you should wait for it, but once it's done it doesn't matter if it passed or failed".
Intended users
User experience goal
Proposal
Add a way to specify whether it should block on that particular job. The default (current behavior when unspecified) is not to block on manual jobs (i.e., run immediately).
Note that this behavior is only relevant when need
ing a manual job, so if someone indicates that they want to block (or not) on a non-manual job, we should provide a linter warning.
Syntax:
job1:
needs: [a, b, c, { job: d, blocking: true }, e, f]
The default value, when not explicitly overridden, is false
(which is the current behavior today).
Note that this should work in concert with #30680 (closed) in cases where both are provided.
Further details
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
- This issue came from a long thread at #31264 (comment 388243579) where we were discussing fixing several issues. It is not required reading to understand the issue, but could be helpful for deeper context if interested.
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.