Bitbucket "condition" changesets - Step Skipped or Always Runs

By Daniel Zoghalchali·Latchkey

A step condition with changesets.includePaths runs the step only when a matching file changed. A glob that never matches silently skips the step; one that is too broad runs it every time.

What this error means

A step you expected to run is skipped (or one you expected to skip keeps running). There is no error - the condition simply evaluated against the changed files differently than you assumed.

condition:
  changesets:
    includePaths:
      - "backend/*"   # only top-level files in backend/, NOT backend/api/x.py

Common causes

Glob does not match nested paths

A pattern like backend/* matches files directly in backend/ but not backend/api/handler.py. To match nested files you need backend/**.

Condition evaluated against an unexpected diff

Changesets compare against the appropriate base for the trigger. On a multi-commit push or a first build, the set of changed files may be wider or narrower than the single commit you have in mind.

How to fix it

Use recursive globs for nested files

Match whole subtrees with ** so nested changes trigger the step.

- step:
    name: Backend tests
    condition:
      changesets:
        includePaths:
          - "backend/**"
    script: [ ./test-backend.sh ]

Verify which files the condition sees

1. Add a temporary step that prints the changed files to confirm the diff base.
2. Test the glob against those paths (top-level vs nested).
3. Remember conditions are an optimization - a step that must always run should not depend on one.

How to prevent it

• Use ** to match files in nested directories.
• Do not gate must-run steps on changesets.
• Confirm the diff base for your trigger before relying on path matching.

Frequently asked questions

Related guides

References

• GitHub Actions documentation