Skip to content

Support cache policies for job rules

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Update

workaround is available in #270415 (comment 1050526105)

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

Intended users

Further details

Proposal

Add cache to rules to specify policy. To use the example from the problem to solve section, this would look like:

workflow:
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"
      cache:
        policy: push

my_job:
  ...
  rules:
    - if: $MY_OTHER_VAR == "true"
      cache:
        policy: pull

An override will by definition always take precedence over anything set under cache 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

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.

Edited by 🤖 GitLab Bot 🤖