Introducing Package triggers in Bitbucket Pipelines

In November 2025, we introduced new triggers and workflows to Bitbucket Pipelines to help teams manage and scale complex CI/CD workflows. We later extended that foundation with additional event-based triggers for pipeline, deployment, and pull request events.

We’re now extending that model with a new package-artifact-created trigger. This trigger lets you automatically run custom pipelines when a package artifact is created, making it easier to connect package publishing activity with follow-up automation such as validation, promotion, deployment, notifications, or downstream release workflows.

Why it matters

Package creation is often a key handoff point in the software delivery lifecycle. Once an artifact has been published to Bitbucket Packages, teams may need to verify metadata, run additional security checks, update release notes, promote the package to another environment, or notify dependent teams. With package-artifact-created, that orchestration can happen directly in Bitbucket Pipelines without extra glue code or manual steps.

• Automate post-publish workflows: Run validation, scanning, promotion, or notification pipelines as soon as a package artifact is created.
• Keep workflows composable: Reference focused custom pipelines from trigger conditions instead of building one oversized pipeline.
• Target the right packages: Use the new package related trigger variables in conditions so automation only runs for the package type, package name, or artifact name you care about.
• Improve delivery consistency: Make package-related actions repeatable and observable as normal Bitbucket Pipelines runs.

How it works

Like other event-based triggers, package-artifact-created is configured in the top-level triggers section of your bitbucket-pipelines.yml file. Each trigger can include one or more condition blocks. When Bitbucket detects a matching package artifact creation event and the condition evaluates to true, all referenced custom pipelines run in parallel.

triggers:
  package-artifact-created:
    - condition: BITBUCKET_TRIGGER_PACKAGES_PACKAGE_TYPE == "CONTAINER" && BITBUCKET_TRIGGER_PACKAGES_PACKAGE_NAME == "ubuntu"
      pipelines:
        - validate-package
        - notify-release-channel

pipelines:
  custom:
    validate-package:
      - step:
          name: Validate package artifact
          script:
            - echo "Validating $BITBUCKET_TRIGGER_PACKAGES_PACKAGE_TYPE package $BITBUCKET_TRIGGER_PACKAGES_PACKAGE_NAME artifact $BITBUCKET_TRIGGER_PACKAGES_ARTIFACT_NAME"
            - ./scripts/validate-package.sh
    notify-release-channel:
      - step:
          name: Notify release channel
          script:
            - ./scripts/notify-release.sh

Because triggers fan out, every referenced custom pipeline under a matching condition can run at the same time. This makes it simple to split package-related automation into small, reusable pipelines while keeping the event logic in one place.

Variables available to conditions and scripts

The package-artifact-created trigger includes package-specific variables that can be used in trigger conditions and by the pipelines that run from the trigger. These variables help you identify the package event that started the workflow.

Variable	Description
BITBUCKET_TRIGGER_PACKAGES_PACKAGE_TYPE	The type of the package, for example CONTAINER or MAVEN.
BITBUCKET_TRIGGER_PACKAGES_PACKAGE_NAME	The name of the package, for example ubuntu or com.atlassian:my-library.
BITBUCKET_TRIGGER_PACKAGES_ARTIFACT_NAME	The name of the artifact. For Docker containers, this is the ID of the manifest, such as manifest:sha256:1646cefe9f37d36912d5a179eabef4a91ace6489377b252fe7dd3eeb062eabab. For Maven packages, it is the version, such as 1.0-SNAPSHOT.

Example: run different workflows for different package artifacts

You can combine variables with logical operators and functions such as glob() to control which package events start which pipelines.

triggers:
  package-artifact-created:
    - condition: BITBUCKET_TRIGGER_PACKAGES_PACKAGE_TYPE == "MAVEN" && glob(BITBUCKET_TRIGGER_PACKAGES_ARTIFACT_NAME, "*-SNAPSHOT")
      pipelines:
        - run-snapshot-checks
    - condition: BITBUCKET_TRIGGER_PACKAGES_PACKAGE_TYPE == "MAVEN" && !glob(BITBUCKET_TRIGGER_PACKAGES_ARTIFACT_NAME, "*-SNAPSHOT")
      pipelines:
        - promote-release-package
        - generate-package-release-notes

pipelines:
  custom:
    run-snapshot-checks:
      - step:
          name: Run snapshot checks
          script:
            - ./scripts/check-snapshot.sh
    promote-release-package:
      - step:
          name: Promote release package
          deployment: production
          script:
            - ./scripts/promote-package.sh
    generate-package-release-notes:
      - step:
          name: Generate package release notes
          script:
            - ./scripts/generate-release-notes.sh

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.
• package-artifact-created triggers do not re-trigger on the creation of artifacts they themselves created (no infinite loops!).
  • We prevent this re-trigger by checking the package-artifact-created associated pipeline’s trigger. If it is package-artifact-created, we do not re-trigger the pipeline.
  • Avoid using package-artifact-created triggers together with deployment-completed or pipeline-completed triggers in ways that create cycles. If a package-artifact-created trigger starts a deployment pipeline and a deployment-completed or pipeline-completed trigger then creates another artifact, the process can loop.

With package-artifact-created, Bitbucket Pipelines can react when a package artifact is published and automatically continue the delivery workflow from there. It’s another step toward making CI/CD orchestration more event-driven, modular, and easier to scale.