Skip to main content

2 posts tagged with "branches"

View All Tags

ยท 3 min read

Call one of the following when a branch is deleted in your CI systems to improve your Pact Broker performance.

  • Pact CLI's pact-broker delete-branch command
  • Pact Broker's API endpoint http://broker/pacticipants/$APPLICATION_NAME/branches/$BRANCH

Most CI systems provide event triggers which can be used to detect branch deletion events.

Back in 2021, the Pact Broker introduced the concepts of Branches and environments, rather than overloading tags, for both purposes. This came with a range of benefits, described in this post.

We've seen rafts of you switch over to the new state of Pact Nirvana, utilizing branches and environments, to their full effect and today I'd like to share a little tip, to help keep your Pact Broker working at it's optimum.

It is important to have good hygiene in your Pact Broker, ensuring that when you remove applications, branches, or environments from your version control system (github/bitbucket etc), you reflect the same within your broker.

Doing so, will improve performance when fetching pacts for verification and is highly recommended if you are deeply reliant on the can-i-deploy matrix's output, to keep query times as low as possible.

Removing stale branches is one of the easiest, and yet most overlooked areas of these, so I'm going to show you a couple of different techniques you can use.

Delete Branch Methodsโ€‹

Removes a branch from a pacticipant version. Does not delete the actual pacticipant version.


Send a DELETE request to the branch version resource.

Pact Broker - No Auth - Delete Branchโ€‹


Pact Broker - Basic Auth - Delete Branchโ€‹


PactFlow Broker - Bearer Auth - Delete Branchโ€‹

curl -H "Authorization: Bearer $PACT_BROKER_TOKEN" \


If you want to check if your Pact Broker has support for the above relation, you can call the Pact Broker index, and check for the existence of _links."pb:pacticipant-branch"

Pact Broker - No Auth - Indexโ€‹

| jq '._links."pb:pacticipant-branch"'

Pact Broker - Basic Auth - Indexโ€‹

| jq '._links."pb:pacticipant-branch"'

PactFlow Broker - Bearer Auth - Indexโ€‹

curl -H "Authorization: Bearer $PACT_BROKER_TOKEN" $PACT_BROKER_BASE_URL \
| jq '._links."pb:pacticipant-branch"'

Pact CLIโ€‹

pact-broker delete-branch \
--pacticipant "$APPLICATION_NAME" \
--branch "$BRANCH" \


The Pact CLI is PACT_BROKER_* environment variable aware, so if you have your Basic Auth PACT_BROKER_USERNAME/PACT_BROKER_PASSWORD, or Bearer Auth PACT_BROKER_TOKEN environment variables set, the CLI will pick them up.

In our example above, PACT_BROKER_BASE_URL is set in our shell prior to executing.

You can explicitly set those values with

-b, --broker-base-url=BROKER_BASE_URL
# The base URL of the Pact Broker
-u, [--broker-username=BROKER_USERNAME]
# Pact Broker basic auth username
-p, [--broker-password=BROKER_PASSWORD]
# Pact Broker basic auth password
-k, [--broker-token=BROKER_TOKEN]
# Pact Broker bearer token


GitHub Actionsโ€‹

name: Delete application branch in a Pact Broker

- "*"

name: delete
runs-on: ubuntu-latest

- name: Install Pact CLI
run: |
curl -fsSL | sh
echo "PATH=${PATH}:${PWD}/pact/bin/" >>$GITHUB_ENV

- name: Delete branch
run: |
pact-broker delete-branch \
--pacticipant "$APPLICATION_NAME" \
--branch "${{ github.event.ref }}" \
PACT_BROKER_BASE_URL: "https://your-broker-url"
APPLICATION_NAME: 'example-consumer'

Go forth and delete all the things!

ยท 7 min read

Tags that represent branches and environments are being replaced with first class support for branches, environments, deployments and releases.

"Tags" in the Pact Broker are simple string values that belong to application version resources (aka. "pacticipant versions") that are generally used to track the git branches and environments associated with an application version. They allow us to identify specific versions when testing backwards compatability and introducing new features, and when determining if an application is safe to deploy. Tags have the advantage of being flexible and generic enough to support any development workflow.

Tags have their disadvantages though. They are similar enough to Docker tags that users expect them to work the same way, but different enough that pages of documentation need to be written to explain how to use them. The main problem with tags though, is that no semantic information that can be inferred from them - that is, it's impossible for the Broker to know whether a tag represents a git branch, an environment, or something else entirely.