Fix rules for trigger deploy kube job

Marcel Amiraultrequested to merge
fix-docs-pipelines-default-branch into main

What does this MR do?

Update the rules for trigger deploy to kubernetes:, as the entry added in Make sure deploy to kubernets works only on main (!5352 - merged) broke pipelines on main every time we merge a docs-only MR:

Related to Deploy each commit from main to kubernetes cluster (!5314 - merged) (which had incorrect rules:).

Why was this MR needed?

In the original iteration, we use extends to pull in the main rules, but then by adding a single extra rules section to skip MR pipelines, we overwrite all the rules pulled in from extends:

trigger deploy to kubernetes:
  extends: .trigger-downstream-pipeline-ref-rules
  needs:
    - trigger UBI images build
  rules:                                                # the rule below overrides the rules from extends
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" 
      when: never
  trigger:
    project: gitlab-org/ci-cd/runner-tools/runner-kubernetes-infra

So we attempted to fix this in !5352 (merged) by adding one more rule to force it to run on default branch pipelines. But this was already handled in .trigger-downstream-pipeline-ref-rules so the addition wouldn't have been needed if we weren't accidentally overwriting the rules.

This was also missing the needed changes section to prevent this from running on docs-only pipelines.

trigger deploy to kubernetes:
  extends: .trigger-downstream-pipeline-ref-rules
  needs:
    - trigger UBI images build
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: never                                        # the new rule below is enabling this job in _all_ pipelines, with no `changes`
    - if: $CI_PROJECT_PATH == "gitlab-org/gitlab-runner" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: always
  trigger:
    project: gitlab-org/ci-cd/runner-tools/runner-kubernetes-infra

So this MR reverts to using the same rules as in .trigger-downstream-pipeline-ref-rules, but copied down as we're overriding the ones from extends. So now we can then set MR pipelines to never, as I believe was the original intention, but we keep the extends so that we still get the stage and variables from that section.

What's the best way to test this MR?

What are the relevant issue numbers?

Edited by Marcel Amirault

Merge request reports