Support `variables` for job `rules`

Release notes

Previously 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)

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:

# 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

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

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