Bitbucket "branches:" vs "default:" - Wrong Pipeline Runs
On a push, Bitbucket runs the most specific matching branches: glob, falling back to default: only when nothing matches. A surprising glob match - or a missing default - runs the wrong pipeline or none at all.
What this error means
A push runs a different pipeline than you expected, or runs nothing. A broad glob shadowed the one you wanted, or there was no default: to catch a branch no glob matched.
pipelines:
branches:
'*': # matches EVERY branch, shadowing more specific intent
- step: { script: [ ./generic.sh ] }
'release/*': # never reached for release/x because '*' matched first
- step: { script: [ ./release.sh ] }Diagnose it: schema, branch match, or step isolation?
Bitbucket validates the pipeline file on push, and a schema error disables the pipeline rather than failing a build, which looks like nothing happened. Each step also runs in a fresh container, so nothing carries between steps unless declared.
curl -X POST -H "Content-Type: application/x-yaml" \
--data-binary @bitbucket-pipelines.yml \
https://api.bitbucket.org/2.0/repositories/<workspace>/<repo>/pipelines/validateCommon causes
A broad glob shadows a specific one
Bitbucket picks the matching branch pipeline by specificity rules. An overly broad pattern like * can match before the specific release/* you intended.
No default catch-all
Without a default: section, a branch that matches no branches: glob runs nothing - the push silently produces no pipeline.
How to fix it
Order globs from specific to general and add default
Use precise globs and a default: fallback so every branch maps to exactly one intended pipeline.
pipelines:
default:
- step: { script: [ ./ci.sh ] }
branches:
'release/*':
- step: { script: [ ./release.sh ] }
main:
- step: { script: [ ./deploy.sh ] }Verify which pipeline a branch resolves to
- Push to a test branch and confirm the expected section ran.
- Remove or narrow broad globs that unintentionally match.
- Keep a
default:unless some branches should intentionally skip CI.
How to prevent it
- Prefer specific branch globs over broad wildcards.
- Include a
default:catch-all unless skipping CI is intended. - Test branch matching on a throwaway branch before relying on it.