<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Jobs in a pipeline may not get created if other jobs - which have rules assigned to them - get created. I noticed it specifically testing some jobs which tested merge request variables: ``` - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME != "release"' ``` These issues seem to be in the same kind of space, they're the best hits I found, * https://gitlab.com/gitlab-org/gitlab/issues/33819 * https://gitlab.com/gitlab-org/gitlab/issues/33694 (some of the comments on this suggest that it might be related) **Workaround:** add a rule to the other jobs that'll always return success, such as testing for a variable which is always present. ```yaml rules: - if: '$CI' ``` ### Steps to reproduce * New repo on gitlab.com * Create master with readme. * Push an identical branch called release * I've changed the default branch and set protection on branches like this; I doubt it's relevant.  * settings/general  * Create a feature branch with this `.gitlab-ci.yml` ([link to the branch reproducing this](https://gitlab.com/bprescott-support/testing/issue194129-cirules/commits/twojobs-onerule)) ```yaml stages: - workflow-protection - test testjob1: stage: test script: - echo "${CI_JOB_NAME}" invalid-source-for-merge-to-master: stage: workflow-protection rules: - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME != "release"' script: - /bin/false ``` * Push the branch, [testjob1 will get created. As expected, the other's rule doesn't trigger.](https://gitlab.com/bprescott-support/testing/issue194129-cirules/pipelines/106716861)  * [Create a merge request from the branch to release](https://gitlab.com/bprescott-support/testing/issue194129-cirules/merge_requests/1); * No new CI gets created. Green to merge. * [Create a MR from your branch to master.](https://gitlab.com/bprescott-support/testing/issue194129-cirules/merge_requests/2) * [A new pipeline will kick off](https://gitlab.com/bprescott-support/testing/issue194129-cirules/pipelines/106717524), and both jobs should be created, but they are not. (pipeline failed, merge not available.)  * Fork your feature branch to a new one. Modify `.gitlab-ci.yml` and add `rules:` to testjob1 as below. * [Push it (link to example branch)](https://gitlab.com/bprescott-support/testing/issue194129-cirules/tree/twojobs-tworules) ```yaml stages: - workflow-protection - test testjob1: stage: test rules: - if: '$CI' script: - echo "${CI_JOB_NAME}" invalid-source-for-merge-to-master: stage: workflow-protection rules: - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME != "release"' script: - /bin/false ``` * [Create a MR to merge it to master.](https://gitlab.com/bprescott-support/testing/issue194129-cirules/merge_requests/3) * [Two jobs created in the pipeline.](https://gitlab.com/bprescott-support/testing/issue194129-cirules/pipelines/106719094) (pipeline failed, merge not available.)  ### Example Project https://gitlab.com/bprescott-support/testing/issue194129-cirules ### What is the current *bug* behavior? The creation of the job with the rule interferes with the creation of the other job. ### What is the expected *correct* behavior? One job should always be created, and when the rule triggers, the second job as well. I found it trying to get larger (three stage/three job) pipelines to build. the 'guard' job I was trying to demonstrate would wipe out the entire pipeline. ### Relevant logs and/or screenshots (Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.) ### Output of checks The bug was found on gitlab.com #### Results of GitLab environment info n/a #### Results of GitLab application Check n/a ### Possible fixes (If you can, link to the line of code that might be responsible for the problem)