Skip to content

Start updating runner pipeline to rules

Marcel Amirault requested to merge runner-pipeline-to-rules into master

What does this MR do?

Updates the pipeline to start moving the test.gitlab-ci.yml file away from only/except and start using rules. It also lays the foundation to do this across the other files in followups.

  1. Moves all the only/except and rules to the _rules.gitlab-ci.yml file.

  2. Adds anchors for the various if: patterns, so we can easily reuse the patterns in the 3 rules: configs added (and any future rules).

  3. The first group to change is the .merge_request_pipelines config. This was an only rule, and I changed it to rules. It was very often combined with .except-docs, so I created a second rule to cover that in a similar way. The docs review app needed when: manual, so I created one more rule config for that edge case.

    Before After
    - .merge_request_pipelines - merge_request_pipelines_rules
    - .merge_request_pipelines
    - .except_docs
    - merge_request_pipelines_rules_no_docs
    - .merge_request_pipelines
    when: manual
    - merge_request_pipelines_rules_docs_review

    I applied this change to jobs that could accept it, mostly in test.gitlab-ci.yml.

  4. The secure jobs in test.gitlab-ci.yml were using a .merge_request_pipelines_rules: already. I renamed this .merge_request_pipelines_scanners_rules: for now so it is more clearly separate from the regular rules, and I will clean up that configuration in the next followup.

Why was this MR needed?

As part of #5019 (closed), we should first start using rules in all jobs and stop mixing only/except with rules in the same pipeline. This will get us on the road towards better use of changes:, and pipelines that self-configure based on which files are changed.

What's the best way to test this MR?

What are the relevant issue numbers?

Related to #5019 (closed)

Edited by Marcel Amirault

Merge request reports