How to adopt github merge queues without auto-releasing pre-merge builds?

[ralphbean]

Take a look at the documentation for adopting github merge queues here: https://konflux-ci.dev/docs/patterns/github-merge-queues/#modify-the-on-cel-expression-of-your-pull-request-pipeline

It recommends the following on-cel expressions for your pull request pipelinerun definition:

    pipelinesascode.tekton.dev/on-cel-expression: (event == "pull_request" && target_branch == "main") || (event == "push" && target_branch.startsWith("gh-readonly-queue/main/"))

The thing to notice is that a push event will trigger that pipeline, but only in a certain circumstance where the github merge queue branches are used. This works in that it triggers those PR pipelineruns at the right time, triggers testing, and makes the merge queue proceed safely.

The unexpected side-effect, however, is that the build pipelineruns that complete as a part of that merge queue have the pac.test.appstudio.openshift.io/event-type=push label, and therefore their Snapshots bear that label, and therefore they are a candidate for auto-release even though they're not the resulted of merged PRs.

---

• Does that scenario/diagnosis sound plausible?
• How should we resolve this?

[scoheb]

@ralphbean

This works in that it triggers those PR pipelineruns at the right time, triggers testing, and makes the merge queue proceed safely

when you say testing, do you mean Integration Test Scenarios? or GitHub workflows?

[ralphbean]

Ah, I meant ITSes.