Add an org/repo setting to disable Stacked Pull Requests

[danielkatfavor]

🏷️ Discussion Type

Product Feedback

Body

Stacked pull requests do not need setup. The feature works for a repo as soon as a user makes a stack. Some orgs want to turn this off.

Please add a setting to disable Stacked Pull Requests at the organization level or the repository level.

Reasons for this request:

1. Stacked PRs increase CI cost — each layer in a stack triggers its own full CI run, multiplying job count for what is one logical change.
2. We want changes to land one at a time, in full, rather than as parallel in-review layers.

Current workaround and its gap:

We already restrict CI to only run on pull requests that target our mainline branches. When we tested this against a stack, a CI job ran anyway on an intermediate PR that did not target a mainline branch — the stack bypassed our restriction. Without a real disable option, we have no reliable way to stop CI from running on these PRs.

Request:

• Add a toggle (for example under Organization Settings → Code, planning, and automation, or Repository Settings → General) to turn off Stacked Pull Requests for a repo or org.
• When off, block the creation of new stacks and show a clear message to the user.

[shailesh-zx]

Hey @danielkatfavor ,

Thanks for bringing this up. The concern regarding unnecessary CI consumption on intermediate stacked branches is very valid.

While a native GitHub UI toggle at the Org/Repo settings level doesn't exist yet, you can completely fix the CI cost bypass and block stacked PRs right now using your workflow configurations and PR target rules.

Here is how you can resolve this immediately:

1. Fix the CI Bypass (Stop wasting CI minutes immediately)

If CI is triggering on intermediate PRs (e.g., PR #2 targeting feature-branch-1), it means the pull_request event in your workflow file isn't scoped to specific base branches.

Update your workflow trigger (.github/workflows/ci.yml) to explicitly filter for your mainline branch:

on:

pull_request:

types: [opened, synchronize, reopened]

branches:

  - main # or master / your default branch

Why this works: When someone creates a stacked PR where the base branch is feature-branch-1 (and not main), GitHub Actions will completely skip the pipeline run. It won't consume a single CI minute.

2. Hard-block Stacked PRs (Enforce single-target landing)

If you want to explicitly fail or block any PR that is stacked onto another feature branch, add this light step to the top of your workflow or status checks:

jobs:

validate-pr:

runs-on: ubuntu-latest

steps:

  - name: Block Stacked PRs

    if: github.base_ref != 'main'

    run: |

      echo "::error::Stacked PRs are disabled in this repository. Target branch must be 'main'."

      exit 1

By marking this job as a Required Status Check in your Branch Protection Rules / Rulesets, users will be prevented from merging any PR that doesn't directly target the mainline branch.

Summary

**Immediate Fix:** Scope on.pull_request.branches to [main] so intermediate stacks don't fire CI.


**Enforcement:** Add a github.base_ref check to explicitly fail PRs targeting non-mainline branches.

That being said, +1 for a native Org-level setting toggle (Organization Settings → Code, planning, and automation) to disable stacked target branches cleanly from the UI without requiring custom YAML logic!

[danielkatfavor]

Regarding 1:

on:
  pull_request:
    branches:
      - 'dev'
      - 'release/*'

This is our trigger so that is not the case. I haven't looked but my presumption is that those jobs aren't targeting the other feature branch but instead they are targeting the base branch and including the other feature branch.

2 may work since it'll peek into the PR instead of the PR action, I'll give it try. I was considering a similar workaround.

[34917620]

good

[34917620]

OK

[danielkatfavor]

The second approach does work. It's a pretty annoying workaround though.

[maxnorth]

Came here because of these exact concerns. We have folks exhausting our own runner capacity because people are creating 15 layered PR stacks from agents, which rebase and trigger CI simultaneously for every commit. We also implement a deploy sequencer in our merge queue that ensures PR's can only merge to main once the current HEAD of main has successfully deployed, and now with people able to add stacked PR's to the queue, we're risking unnecessary waits compared to if these were just collapsed to begin with. As an owner of CI/CD, we now have to contend with multiple new issues that turn our previously successful workflow design against us. I imagine we can design around these, but it's quite a pain.

[maxnorth]

Alternately, I would also be good with configurable limits on number of PRs in a stack.

[drc-jonathandunn]

This feature breaks our CI flow as well. We need a way to opt out of this.

[Snazzie]

Please allow us to turn this off. its a terrible feature.