fix(ci): pass merge queue base ref to paths-filter

[yuhao-su]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Connector Node Integration Tests fails on nearly every merge-queue run for a release branch. Example: run 29352468722 on gh-readonly-queue/release-2.8/pr-26262-....

Changes will be detected between main and gh-readonly-queue/release-2.8/pr-26262-...
[command] git fetch --no-tags --depth=100 origin main gh-readonly-queue/release-2.8/...
[command] git merge-base refs/remotes/origin/main refs/remotes/origin/gh-readonly-queue/release-2.8/...
[command] git fetch --deepen=200 origin main gh-readonly-queue/release-2.8/...
fatal: shallow file has changed since we read it
##[error]The process '/usr/bin/git' failed with exit code 128

Root cause

The dorny/paths-filter step passes no base input.

On pull_request the action resolves changed files through the GitHub API, so base is never consulted. On merge_group it takes the git path instead, and with no base it falls back to the repository's default branch — main — even when the merge queue is on a release branch. That is the first line of the log above.

For a merge queue on main the fallback is accidentally correct: the merge base sits right there in the depth=100 shallow clone. For a merge queue on a release branch it is not. main and release-2.8 diverged 541 commits ago (release-3.0: 198). paths-filter then repeatedly runs git fetch --deepen=... looking for the merge base, and git eventually aborts with fatal: shallow file has changed since we read it.

The failure rate tracks the divergence exactly. Over the last ~200 runs of this workflow, restricted to merge_group events:

queue base	success	failure
main	25	1 (a different, benign error — couldn't find remote ref, the queue branch was deleted mid-run)
release-3.0 (198 commits diverged)	7	5
release-2.8 (541 commits diverged)	1	7

The check is not required by the merge queue, so it does not block merges — it just leaves a red cross on the commit and mails the person who enqueued the PR.

There is a second, quieter bug. When the deepening happens to succeed, the diff is still computed against main, so it reports every file that differs between main and the release branch. java/ + proto/ differ by 15 files between main and release-3.0, so java == true always holds and the full Maven build runs for every release-branch merge-queue entry regardless of what the PR touched. Confirmed on run 29337673137, where run integration tests executed rather than being skipped.

The fix

Pass the merge group's real base branch:

base: ${{ github.event.merge_group.base_ref }}

Behavior per event:

• merge_group — base becomes refs/heads/release-2.8. The merge base is one or two commits away and already present in the depth=100 clone, so there is no deepening and no crash, and the diff covers only the PRs actually in the queue.
• pull_request — github.event.merge_group is null, so the expression evaluates to empty. The action already resolves changed files via the GitHub API (Fetching list of changed files for PR#... from Github API) and ignores base. Unchanged.
• push to main — the expression is empty, so paths-filter falls back to the default branch main, which equals the head branch, and it compares against the push's before SHA. Unchanged.

github.base_ref is not populated for merge_group (community discussion #40277), so github.event.merge_group.base_ref is the only way to reach it.

Verification

This is a workflow-config change, so the merge-queue path can only be exercised by an actual merge queue:

• This PR's own pull_request run exercises the base-is-empty path and should behave exactly as before.
• This PR going through main's merge queue exercises the merge_group path with base = refs/heads/main.
• The release-branch path is only proven once this is cherry-picked, since a merge queue runs the workflow as defined on the queue branch, which is based on the release branch. Cherry-picks to release-2.8 and release-3.0 are required for the failures to actually stop.

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• I have checked the Release Timeline and Currently Supported Versions to determine which release branches I need to cherry-pick this PR into. Needs cherry-picking into release-2.8 and release-3.0 — the fix has no effect on a release branch until it is present on that branch.

Documentation

• My PR needs documentation updates.

Release note

[yuhao-su]

• fix(ci): pass merge queue base ref to paths-filter #26273 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.