Skip to content

Use `workflow:rules:` instead of defaults on `only:`

Kamil Trzciński requested to merge workflow-rules-defaults into master

What does this MR do?

Related to #30111 (closed) and !22646 (closed)

This tries to answer the question if we can move away from setting default only/except values in favour of configuring default workflow:rules: used by pipelines.

Idea: Allow legacy branch pipelines on Merge Requests

This if would work would allow us to introduce a project setting, similar to this:

Allow legacy branch pipelines on Merge Requests

This setting would have the following impact:

1. enabled

Inject the following .gitlab-ci.yml:

  workflow:
    rules:
      - if: $CI_COMMIT_BRANCH
      - if: $CI_COMMIT_TAG

This makes us to prefer to create branch pipelines.

MR widget and a list of pipelines shows a MR pipelines and branch pipelines.

2. disabled

Inject the following .gitlab-ci.yml:

  workflow:
    rules:
      - if: $CI_COMMIT_BRANCH == "master"
      - if: $CI_MERGE_REQUEST_ID
      - if: $CI_COMMIT_TAG

This makes us to prefer to create MR pipelines.

MR widget and a list of pipelines shows ONLY MR pipelines.

Impact

By the definition this would allow us (hopefully) to easily switch project from creating and showing branch pipelines to prefer creating and showing MR pipelines by default.

The MR pipelines given all MR trains, and all other features are really prefered us to running pipelines in context of MRs.

This does have a potential issue of breaking changes, not sure when it could break.

Does this MR meet the acceptance criteria?

Conformity

Merge request reports