Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Pact Broker version tags can be used for multiple purposes.
Tags can be used to enable you to test consumer and provider
prodversions against each other. This allows you to decouple the release cycles of your consumer and provider. Read more about this here.
Tags can be used to enable you to add new interactions without breaking all the builds. Read more about this here.
Note that the tag is actually placed on the
version resource, not the
pact itself (conceptually, you are indicating that that particular version of the application is a "prod" version, or a "feature-xyz" version). The URL structures, however, then allow you to retrieve pacts by the tags on their associated versions.
As an example, to tag
Foo consumer version
2.3.0 as the production version, do a
PUT to the resource
/pacticipants/Foo/versions/2.3.0/tags/prod. All the pacts associated with
/pacticipants/Foo/versions/2.3.0 are now considered to be the production pacts. The latest production pact for provider
Bar can then be retrieved from
When you are using tags, you need to ensure that the version numbering scheme you use to identify a "version" cannot give you version that exists on more than one repository branch - don't hard code it. It should either be the git sha (or equivalent for your repository), or it should include the git sha as metadata if you are using semantic versioning eg.
/pacts/provider/PROVIDER/consumer/CONSUMER/latestwill return the latest pact, regardless of tags.
/pacts/provider/PROVIDER/consumer/CONSUMER/latest/TAGwill return the latest pact associated with the specified tag.
/pacts/provider/PROVIDER/consumer/CONSUMER/latest-untaggedwill return the latest pact without any tag
1. Automatically tag with branch name when pact is published (recommended)
With this approach, the consumer version always has a tag, whether it be
feature-x. This approach works well if you use feature branches for development, and release from a production branch.
An example configuration in a ruby project to achieve this would be:
PactBroker::Client::PublicationTask.new do | task | task.pact_broker_base_url = "..." task.consumer_version = "..." task.tag = `git rev-parse --abbrev-ref HEAD`.strip end
The provider CI would then be configured to verify the required branches using the URLs described above - the recommended approach would be to always verify
2. Manually tag production or feature pacts
If you release from master, then the production version of the consumer application should be tagged with
prod as part of the release process. The provider CI should verify the
latest/prod endpoints described above. You can also manually tag pacts with the tag name of your choice to allow you to add in new interactions without breaking the provider CI.