block-remove-before-merge workflow fails on merge_group events (latent merge-queue blocker)

[SteveSandersonMS]

Summary

The block-remove-before-merge.yml workflow (added in #1729, merge commit 079c558) is triggered on merge_group events but cannot work on them, and will fail the run — which would jam the merge queue if/when it's enabled.

Details

The workflow triggers on both pull_request and merge_group:

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
  merge_group:

But it derives the PR number from the pull_request context, which is empty on merge_group events:

PR_NUMBER: ${{ github.event.pull_request.number }}
run: |
  FILES=$(gh api repos/$REPO/pulls/$PR_NUMBER/files --paginate --jq '.[].filename')

On a merge_group event PR_NUMBER is empty, so the call becomes gh api repos/$REPO/pulls//files, which 404s. GitHub Actions runs run: blocks with set -eo pipefail, so the failed command substitution fails the step.

Impact

Currently dormant — the merge queue is not enabled (every run of this workflow so far is a pull_request event; there are no merge_group runs). So this does not break anything today. It is a latent issue: whoever enables the merge queue later will see every merge-queue run fail with a confusing, seemingly-unrelated error.

Suggested fix

The check is inherently PR-scoped, so it should not do its work on merge_group. Either:

• Remove the merge_group: trigger, or

• Skip the job on non-PR events:

  jobs:
    check-paths:
      if: github.event_name == 'pull_request'

If this is intended to be a required status check under a future merge queue, instead short-circuit to success on merge_group (so the queue still sees a green check) rather than skipping the job.

[github-actions]

Investigation findings: confirmed bug ✅

I reviewed the workflow file at .github/workflows/block-remove-before-merge.yml and confirmed the issue.

What I found:

• Line 6: merge_group: trigger is listed alongside pull_request
• Line 19: PR_NUMBER: ${{ github.event.pull_request.number }} — this expression evaluates to an empty string on merge_group events because github.event.pull_request is not populated for that event type
• Line 22: gh api repos/$REPO/pulls/$PR_NUMBER/files — becomes gh api repos/$REPO/pulls//files when PR_NUMBER is empty, which returns HTTP 404 and fails the step (since Actions runs with set -eo pipefail)

The intent of the workflow is clearly to block PR merges that contain remove-before-merge paths. That check is already satisfied before a merge_group event fires (the PR check ran first), so running the same check again in the merge queue context is both unnecessary and broken.

Root cause: The merge_group: trigger was added without accounting for the fact that github.event.pull_request is only populated on pull_request events.

Suggested fix (as noted in the issue): Either remove the merge_group: trigger entirely, or add a job-level condition:

jobs:
  check-paths:
    if: github.event_name == 'pull_request'

If a green status check is required for the merge queue to pass, use if: github.event_name == 'pull_request' with a separate always-passing step for the merge_group case (or set the job to succeed by default on non-PR events).

Labeling as bug — the merge_group trigger is unintentional and would break the merge queue when enabled.

Generated by Bug Handler for issue #1797 · sonnet46 532.3K · ◷

[edburns]

@copilot please respond to this context and question.

Context

The intent of block-remove-before-merge is to prevent a PR from being merged that contains any directories ending with remove-before-merge.

Question

Given this intent, would this problem you have identified cause a blockage to occur for any other reason, other than "the result of this merge would cause one or more directories ending with the name remove-before-merge to be merged to main?

Result

If the answer is "yes" then we can talk further.

If the answer is "no" then this issue should be closed as WONTFIX or whatever equivalent status is used here.