New Triggers for Pipeline, Deployment, and Pull Request Events

In November 2025, we added support for triggers and workflows to Bitbucket Pipelines to help your teams manage and scale complex CI/CD workflows.

Today, we’re excited to extend that foundation with additional event-based triggers to run custom pipelines when other pipelines or deployments complete or when key pull request events occur. This makes it easier to chain workflows, drive targeted automations, and reduce manual steps in your delivery process.

What’s New

New Trigger Types

We’re adding new trigger types to complement the existing repository-push and pullrequest-push:

Trigger Type	System Event
pipeline-completed	A pipeline completes (success or failure)
deployment-completed	A deployment completes
pullrequest-created	A new pull request is created in a repository. This trigger supports [skip ci] functionality.
pullrequest-updated	An existing pull request is updated (new commits, title or description changes, reviewer added/removed). This type does not support [skip ci] functionality.
pullrequest-rejected	A pull request is declined without being merged.This type does not support [skip ci] functionality.
pullrequest-fulfilled	A pull request is merged into its target branch. This type does not support [skip ci] functionality.
pullrequest-reviewer-status-updated	A reviewer’s approval status on a pull request changes (approved, requested changes, etc.). This type does not support [skip ci] functionality.

---

Why it matters

With these triggers, you can connect events across your CI/CD and code review workflows. This helps you:

• Chain build, test, security, and deployment pipelines so later stages only run when earlier ones complete with specific results.
• Drive targeted automation on pull requests, for example running extra checks on fulfillments.
• Reduce manual steps and custom glue code by keeping more orchestration logic inside Bitbucket Pipelines

How it works

You define event-based triggers for custom pipelines in your bitbucket-pipelines.yml file. Each trigger type supports one or more condition statements so you can be precise about when a pipeline should run. Triggers complement existing selectors, so you can combine them for more control.

At a high level:

• In your pipelines yaml, you define custom pipelines that you want to run based on triggers within your repository.
• For a given trigger, you define one or more condition statements to control whether the relevant pipelines will execute.
• Under each condition, you reference one or more custom pipelines, all of which will execute if the condition is true.
• When Bitbucket detects matching triggers and condition statements, it automatically starts the configured custom pipelines.

---

Configuring event-based triggers in bitbucket-pipelines.yml

Here are some examples of how to configure a pipeline using triggers and conditions.

In this example, a pipeline runs when a new PR is created:

triggers:
  pullrequest-created:
    - condition: glob(BITBUCKET_BRANCH, "feature/*")
      pipelines:
        - pr-created-pipeline

pipelines:
  custom:
    pr-created-pipeline:
      - step:
          name: Pull Request Created Pipeline
          script:
            - echo "This pipeline runs when a pull request is created for feature/* branches"
            - ./scripts/run-tests.sh

Chain pipelines together! This pipeline uses the pipeline-completed trigger to call the next pipeline based on the status of the build.

triggers:
  pipeline-completed:
    - condition: BITBUCKET_TRIGGER_PIPELINE_STATUS == "FAILED"
      pipelines:
        - send-notification

pipelines:
  default:
    - step:
        name: Failing Step
        script:
          - echo "This step is designed to fail"
          - exit 1;
  custom:
    send-notification:
      - step:
          name: Send notification for failed build
          script:
            - ./scripts/notify-users.sh

This example uses the pullrequest-updated trigger with the changesetInclude function:

triggers:
  pullrequest-fulfilled:
    - condition: changesetInclude("**.md")
      pipelines:
        - generate-release-notes-pipeline
  pullrequest-updated:
    - condition: changesetInclude("src/**", "lib/**")
      pipelines:
        - run-tests-pipeline  
pipelines:
  custom:
    run-tests-pipeline:
     - step:
          name: Run Tests
          script:
            - ./scripts/run-tests.sh
    generate-release-notes-pipeline:
      - step:
          name: Generate release docs
          script:
            - ./scripts/generate-release-notes.sh

---

New Variables for Conditions

pipeline-completed and deployment-completed triggers comes with their own set of variables that you can use in condition expressions as shown in above examples. For a full list of new variables and what they do, please reference the product documentation.

---

Using triggers with Dynamic Pipelines

Dynamic Pipelines provided by Forge apps can also participate in these event-based triggers. To do this, your app’s manifest needs to declare the trigger types it supports, including any of:

• repository-push and pullrequest-push
• pipeline-completed and deployment-completed
• pullrequest-created, pullrequest-updated, pullrequest-rejected, pullrequest-fulfilled, reviewer-status-updated

---

Things to know

• Only custom pipelines can be referenced in triggers.
• A maximum of 20 conditions per trigger type are supported.
• A maximum of 100 pipelines can be initiated from a single trigger.
• Triggers complement selectors — if both match, pipelines from both mechanisms will run.
• pipeline-completed triggers do not re-trigger on the completion of pipelines they themselves started (no infinite loops!).
  • We prevent this re-trigger by checking the completing pipeline’s trigger. If it is pipeline-completed, we do not re-trigger the pipeline.
• Avoid using pipeline-completed triggers together with deployment-completed triggers in ways that create cycles.If a pipeline-completed trigger starts a deployment pipeline and a deployment-completed trigger then starts another pipeline, the process can loop.

---

Feedback

We’re always keen to hear your thoughts and feedback – if you have any questions or suggestions on this feature, feel free to share via the Pipelines Community Space.