### Release notes Previously [rules](https://docs.gitlab.com/ee/ci/yaml/#rules) keyword used to determine if a job should be include or exclude from pipelines, in this release we've enhanced rules capabilities so users could decide if certain conditions are met to override variables in jobs allowing higher flexibility when configuring your pipelines. ### Problem to solve Rules define when certain jobs can be run, but they could also provide overrides for configuration. This would be a handy way to set up rules for when certain policies or variables should be set. One example use case would be making cache-policy settable by “rules” to say for example that you only want to update the cache pull-push on master and not on branches. Another could be setting `interruptible` using various rules. ### Intended users * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) ### Further details ### Proposal In this issue, we only add `variables` to the `rules`. Other configs can be added in further iterations. Add `variables` to rules to specify variables. To use the example from the problem to solve section, this would look like: ```yaml # This will be implemented in #294232. workflow: rules: - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" variables: MY_VAR: "hello" my_job: ... rules: - if: $MY_OTHER_VAR == "true" variables: MY_VAR2: "hello" # would only be set for this job MY_VAR: "hello2" # overwrite workflow-level override, for this job ``` An override will by definition _always_ take precedence over anything set under `variables` in a job or in the pipeline; job-level overrides take precedence over workflow level overrides. We should use the same evaluation policy for rules that conflict as we do for `when`, which is that (only) first matching rule wins. ### Permissions and Security N/A ### 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 If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> Need to make sure we document that, just like the rest of `rules`, the first matching `rule` wins and only the overrides for that rule will be applied. If other rules also match, they will not be also applied (after the first match). ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? 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? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? N/A in terms of metrics. This would however make pipelines easier to configure in complex use cases. ### What is the type of buyer? Individual contributor who writes pipelines ### 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 -->