Skip to content

The mitigation here implies both branches-ignore (on push) and restricting pull_request to the default branch are needed to stop merge-queue-related runs. In practice, the extra runs come from the merge queue pushing to gh-readonly-queue/**, so branches-ignore on push addresses that; tightening pull_request doesn’t prevent the merge-queue push-triggered runs and could unintentionally stop validation for PRs targeting non-default branches. Consider rewording to make the pull_request.branches restriction optional/separate, and (if relevant) call out that workflows required for merge queue checks should use the merge_group event instead of relying on push to queue branches. #78

@sin-strokes

Description

@sin-strokes

The mitigation here implies both branches-ignore (on push) and restricting pull_request to the default branch are needed to stop merge-queue-related runs. In practice, the extra runs come from the merge queue pushing to gh-readonly-queue/**, so branches-ignore on push addresses that; tightening pull_request doesn’t prevent the merge-queue push-triggered runs and could unintentionally stop validation for PRs targeting non-default branches. Consider rewording to make the pull_request.branches restriction optional/separate, and (if relevant) call out that workflows required for merge queue checks should use the merge_group event instead of relying on push to queue branches.

> If your repository uses a merge queue, the `push` trigger above will also run when pull requests are added to the merge queue, because the merge queue pushes to `gh-readonly-queue/**` branches. To prevent these extra runs, add `branches-ignore: ['gh-readonly-queue/**']` to the `push` trigger. If you only want to validate pull requests that target your default branch, you can additionally restrict the `pull_request` trigger with `branches: [YOUR-DEFAULT-BRANCH]`, but this is optional and will stop validation for pull requests targeting other branches. For workflows that must participate in merge queue checks, consider using the `merge_group` event instead of relying on `push` to queue branches. For more information, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue).

Originally posted by @Copilot in github/docs#43247 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions