ci: skip pipelines for ephemeral glab-* test refs

What

Adds a workflow:rules block that declines to create pipelines for refs named glab-*.

workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME =~ /^glab-/
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: never
    - when: always

Why

Every pipeline this project has run since 2026-09-18 has failed, and all of them are on glab-publish-it-<timestamp> refs. Two more arrived while this was being written. The only pipeline in the project's history that ever passed is iid 1, on master, from 2022.

None of them fail for an interesting reason. They never reach a script:

Fetching changes with git depth set to 20...
fatal: couldn't find remote ref refs/heads/glab-publish-it-1789996704
ERROR: Job failed: exit code 128

Test_MrNotePublish_Integration in gitlab-org/cli creates a throwaway branch here, commits to it, opens a merge request, then deletes the branch in cleanup. Both writes start a pipeline. The test finishes in a few seconds, so by the time a shared runner claims a job the ref is gone. Two dead pipelines per integration run, forever.

It is the first glab integration test to write refs into this project: across all nine *_integration_test.go files on gitlab-org/cli's main, CreateBranch and CreateCommit appear only in that one. The others create issues, toggle the archived flag, or clone, none of which starts a pipeline.

Why fix it here rather than in the test

The test needs a per-run branch. Draft notes are per-user and every integration run authenticates as the same GITLAB_TOKEN_TEST user, so a shared long-lived fixture merge request would have concurrent runs overwriting each other's drafts. The isolation is load-bearing.

[ci skip] in the test's commit message was the other candidate. It only suppresses one of the two pipelines: the branch-creation pipeline inherits master's tip commit message, not the test's.

Fixing it here also covers any future test that needs a disposable ref, which is why the rule matches the glab- prefix rather than glab-publish-it- specifically. Tests that want a throwaway ref in this project should name it glab-<something>.

Why the second rule exists

The first commit had only the glab- rule plus a - when: always catch-all, and that was wrong. Any workflow:rules block replaces GitLab's implicit default, and that default created no merge request pipelines here, because no job opts into merge_request_event. The catch-all therefore switched them on: this merge request's own first commit produced both a branch pipeline (iid 16) and a merge request pipeline (iid 17) for the same SHA. The second commit adds the merge_request_event guard so behavior for every non-glab- ref is exactly what it was before.

Worth knowing if anyone adds workflow:rules to a project expecting it to be purely subtractive. It isn't.

Blast radius

No job names, stages, or scripts change, so anything asserting on the build1 / test2:no_suffix:test / deploy5:really_a_long_name_for fixture jobs is unaffected. $CI_COMMIT_REF_NAME rather than $CI_COMMIT_BRANCH so the rule covers tag refs as well as branches.

No glab integration test depends on a pipeline running in this project. The five that use it (issue/create, issue/update, mr/note/publish, project/archive, project/clone) all assert against the API.

Verification

• POST /projects/:id/ci/lint on the final content: valid: true, no errors, no warnings. The merged YAML shows all three rules parsed as intended.
• This branch is named ci/..., so it does not match the glab- rule and should still get one push pipeline per commit, and no merge request pipeline. That is the positive check that the rules are neither too broad nor a behavior change for normal refs.

Not addressed here: the duplicate report2: key at the bottom of the file, which silently discards the first of the two blocks. Pre-existing, and I left it alone in case a test depends on the current job list.

The companion change trimming the test itself is gitlab-org/cli!3945 (merged).

🤖 Generated with Claude Code