How to Define a Custom Pipeline Trigger in Bitbucket Pipelines

By Daniel Zoghalchali·Latchkey

Pipelines under custom: do not run automatically; an operator launches them by name.

Define a named pipeline under custom: and it appears in the Run pipeline menu. Use it for on-demand tasks like releases or data jobs that should never trigger on push.

A named manual pipeline

Pipelines under custom: are launched on demand, optionally with variables.

pipelines:
  custom:
    release:
      - variables:
          - name: VERSION
      - step:
          name: Release
          script:
            - echo "Releasing ${VERSION}"
            - ./release.sh "${VERSION}"

Notes

• The variables list prompts the operator for input when they start the custom pipeline.
• Custom pipelines can also be started via the Bitbucket REST API for scripted releases.

Verify it actually works

Bitbucket validates bitbucket-pipelines.yml on push, and a schema error disables the pipeline rather than failing a build, which can look like nothing happened at all.

# validate before pushing
curl -X POST -H "Content-Type: application/x-yaml" \
  --data-binary @bitbucket-pipelines.yml \
  https://api.bitbucket.org/2.0/repositories/<workspace>/<repo>/pipelines/validate

# confirm which pipeline definition matched
# Pipelines -> the run -> "Configuration" tab

Constraints that catch people out

• Each step runs in a fresh container. Nothing persists between steps unless it is declared as an artifact or a cache.
• The default memory allocation per step is limited, and service containers share that budget, so adding a database service can push a previously passing build into an out-of-memory failure.
• Only branches with a matching branches: definition run; a push to an unmatched branch silently runs nothing.
• Artifacts are passed forward only to later steps in the same pipeline, not between pipelines.

Frequently asked questions

Related guides

References

• GitHub Actions documentation