### Release post With the implementation of our directed acyclic graph (DAG) in GitLab CI we introduce a syntax that makes a job run only if a different job finish its run (without waiting to its own stage). however if the DAG syntax is combined with rules syntax - which detairmine if a job will gets added to a pipeline there can be a situation where a job is waiting for a job that does not exists in the pipeline (because it did not got added to the pipeline), this will cause the pipeline to fail only on run. In this release we are adding the optional keyword to any DAG job which will process the pipline with the condition that `If the optional job exists, then wait for it, otherwise run as part of the chosen stage`, this will allow you to saifly combined the very popular rules syntax with the growing popularity of the DAG concept ### Problem to solve We are implementing an MVC for a directed acyclic graph (DAG) execution model in GitLab CI via https://gitlab.com/gitlab-org/gitlab-ce/issues/47063#note_198535521, which introduces the following syntax for marking a job as running after another job, without waiting for its own stage: ```yaml deploy: stage: deploy needs: [test] ... ``` A "smart default" we chose was for anything indicated as _needed_ by a job was in fact needed, and if the job did not exist (likely because it didn't match to the pipeline's `only/except` rules), that it would also not run. However, there are some unusual cases where the intent would be: `If job _x_ exists, then wait for it, otherwise run as part of the chosen stage` This is not possible with the current syntax, and this limits usefulness of a whole DAG feature significantly. Due to other limitations teams are often forced to duplicate jobs, this in turn causes snowball effect for DAG, where there is currently no way to express `needs: [A or B]`. Allowing to specify job in `needs` which might not exist in the given pipeline makes gitlab-ci.yml files more concise. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal We can make this easier by allowing you to specify that the job should go ahead if the job it refers to does not exist: ```yaml job1: needs: [a, b, c, { job: d, optional: 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 https://gitlab.com/gitlab-org/gitlab/-/issues/233876 in cases where both are provided. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->