“Auto-cancel redundant workflows” on non-default branches

Build Environment
, ,
1

Hello,

We would like to clarify whether the “Auto-cancel redundant workflows” feature can be extended to branches other than the default branch.

Based on the current behavior and documentation:

“With the exception of your default branch, we will automatically cancel any outstanding workflows on a branch when a newer pipeline is triggered on that branch.”

Our understanding is that only the default branch is excluded from auto-canceling previous workflows, while all other branches have their running workflows canceled when a new pipeline is triggered.

Use case:
We maintain multiple long-lived branches (e.g., 4.0, 5.0, 6.0) and would like these branches to behave like the default branch—meaning workflows should not be auto-canceled on these branches, while the feature remains active for all others.

We are aware that the default branch is defined via the vcs_info field, for example:

https://circleci.com/api/v2/project/github/<mycompany>/<myproject>

{
  ...
  "vcs_info": {
    "default_branch": "4.0"
  }
  ...
}

Additionally, we came across a workaround in the CircleCI community forum that suggests disabling the feature entirely and implementing a custom/scripted mechanism to cancel previous workflows manually:
https://discuss.circleci.com/t/workaround-auto-cancel-redundant-builds-on-the-default-branch/39468

However, given the number of workflows we maintain, this approach would be quite cumbersome and difficult to scale.

We also attempted to use pr_only_branch_overrides to define specific branches:

GET https://circleci.com/api/v2/project/github/<mycompany>/<myproject>/settings 

{
  "advanced": {
    "autocancel_builds": true,
    "build_prs_only": true,
    "pr_only_branch_overrides": [
      "4.0",
      "5.0",
      "6.0"
    ]
  }
}

However, this configuration does not appear to have any effect on the auto-cancel behavior.

Questions:

  1. Is it possible to configure multiple branches to behave like the default branch for this feature?

  2. If not, is there any workaround or alternative approach to selectively disable auto-cancel for specific branches?

Thank you for your support.

Best regards,
João

2

Hi João,

Thank you for the detailed write-up — you’ve clearly done your homework here, and your understanding of the current behavior is exactly right.

To directly answer your questions:

  1. It is not currently possible to configure multiple branches to behave like the default branch. The auto-cancel feature treats exactly one branch (the configured default) as protected. There is no native way to extend that protection to additional long-lived branches like 4.0, 5.0, or 6.0.

  2. The pr_only_branch_overrides field you tried is specifically for controlling PR-only build behavior, so unfortunately it has no effect on auto-cancel — good investigative work ruling that out.

Workaround

The scripted approach you found is the most viable option today. To make it less cumbersome to scale across many workflows, you can centralize the logic in a reusable orb or a shared command that checks $CIRCLE_BRANCH against a list of protected branches before deciding whether to cancel. That way it’s a one-line addition to any workflow rather than duplicating the script everywhere. If it’s helpful, here’s a rough sketch of that pattern:

steps:
  - run:
      name: Skip auto-cancel for protected branches
      command: |
        PROTECTED_BRANCHES="4.0 5.0 6.0"
        for branch in $PROTECTED_BRANCHES; do
          if [ "$CIRCLE_BRANCH" = "$branch" ]; then
            echo "Protected branch — skipping cancel."
            exit 0
          fi
        done
        # ... cancel logic here

This is a known limitation we’d love to improve

Your use case — multiple long-lived release branches that should be exempt from auto-cancel — is exactly the kind of feedback that shapes our roadmap. We have two open feature requests on our ideas board that are directly relevant:

If you could add a vote and drop a comment on those posts describing your release branch setup, it would be really valuable signal for our product team — the more concrete use cases we can attach to a request, the stronger the case for prioritization.

Hope that helps clarify things — happy to answer any follow-up questions!