A client for the Pact Broker. Publishes and retrieves pacts, verification results, pacticipants, pacticipant versions and tags. The functionality is available via a CLI, or via Ruby Rake tasks. You can also use the Pact CLI Docker image.
Download the latest pact-ruby-standalone package. You do not need Ruby to run the CLI, as the Ruby runtime is packaged with the executable using Travelling Ruby.
To connect to a Pact Broker that uses custom SSL cerificates, set the environment variable $SSL_CERT_FILE or $SSL_CERT_DIR to a path that contains the appropriate certificate.
You will need >= v2.13.0 of the Pact Broker for this feature to work. See the Can I Deploy page in the Pact docs for an explanation of how can-i-deploy works under the hood.
[--retry-while-unknown=TIMES] # The number of times to retry while there is an unknown verification result (ie. the provider verification is likely still running)
# Default: 0
[--retry-interval=SECONDS] # The time between retries in seconds. Use in conjuction with --retry-while-unknown
# Default: 10
Description:
Returns exit code 0 or 1, indicating whether or not the specified pacticipant versions are compatible. Prints out the relevant
pact/verification details.
The environment variables PACT_BROKER_BASE_URL, PACT_BROKER_BASE_URL_USERNAME and PACT_BROKER_BASE_URL_PASSWORD may be used
instead of their respective command line options.
Returns exit code 0 or 1, indicating whether or not the specified application (pacticipant) versions are compatible (ie. safe to deploy). Prints out the relevant pact/verification details, indicating any missing or failed verification results.
The environment variables PACT_BROKER_BASE_URL, PACT_BROKER_USERNAME and PACT_BROKER_PASSWORD may be used instead of their respective command line options.
There are two ways to use can-i-deploy. The first (recommended and most commonly used) approach is to specify just the application version you want to deploy and let the Pact Broker work out the dependencies for you. The second approach is to specify each application version explicitly. This would generally only be used if there were limitations that stopped you being able to use the first approach.
To specify an application (pacticipant) version you need to provide:
the name of the application using the --pacticipant PACTICIPANT parameter,
directly followed by one of the following parameters:
--version VERSION to specify a known application version (recommended)
--latest to specify the latest version
--latest TAG to specify the latest version that has a particular tag
--all TAG to specify all the versions that have a particular tag (eg. "all prod" versions). This would be used when ensuring you have backwards compatiblity with all production mobile clients for a provider. Note, when using this option, you need to specify dependency explicitly (see the second usage option).
Using a specific version is the easiest way to ensure you get an accurate response that won't be affected by race conditions.
Recommended usage - allowing the Pact Broker to automatically determine the dependencies#
If you would like the Pact Broker to calculate the dependencies for you when you want to deploy an application into a given environment, you will need to let the Broker know which version of each application is in that environment. To do this, the relevant application version resource in the Broker will need to be "tagged" with the name of the environment during the deployment process:
$ pact-broker create-version-tag --pacticipant Foo --version 173153ae0 --tag test
This allows you to use the following simple command to find out if you are safe to deploy:
$ pact-broker can-i-deploy --pacticipant PACTICIPANT --version VERSION \
--to ENVIRONMENT \
--broker-base-url BROKER_BASE_URL
If the --to tag is omitted, then the query will return the compatiblity with the overall latest version of each of the other applications.
Examples:
Can I deploy version 173153ae0 of application Foo to the test environment?
If you are unable to use tags, or there is some other limitation that stops you from using the recommended approach, you can specify one or more of the dependencies explictly. You must also do this if you want to use the --all TAG option for any of the pacticipants.
You can specify as many application versions as you like, and you can even specify multiple versions of the same application (repeat the --pacticipant name and supply a different version). If you have a monorepo and you deploy a group of applications together, you can either call can-i-deploy once for each application, or you can group them all together by specifying a --pacticipant and --version for each sub-application.
You can use explictly declared dependencies with or without the --to ENVIRONMENT. For example, if you declare two (or more) application versions with no --to ENVIRONMENT, then only the applications you specify will be taken into account when determining if it is safe to deploy. If you declare two (or more) application versions as well as a --to ENVIRONMENT, then the Pact Broker will work out what integrations your declared applications will have in that environment when determining if it safe to deploy. When using this script for a production release, and you are using tags, it is always the most future-proof option to use the --to if possible, as it will catch any newly added consumers or providers.
If you are finding that your dependencies are not being automatically included when you supply multiple pacticipant versions, please upgrade to the latest version of the Pact Broker, as this is a more recently added feature.
Can I deploy all the applications in my monorepo to prod?
$ pact-broker can-i-deploy --pacticipant A --version a7e28207 \
--pacticipant B --version a7e28207 \
--pacticipant C --version a7e28207 \
--to prod \
--broker-base-url BROKER_BASE_URL
Mobile provider use case - can I deploy version b80e7b1b of Bar, all versions of Foo with tag "prod", and the latest version tagged "prod" of any other automatically calculated dependencies together? (Eg. where Bar is a provider and Foo is a mobile consumer with multiple versions in production, and Bar also has its own providers it needs to be compatible with.)
$ pact-broker can-i-deploy --pacticipant Bar --version b80e7b1b \
PactBroker::Client::PublicationTask.new do | task |
require 'my_consumer/version'
task.consumer_version = MyConsumer::VERSION
task.pattern = 'custom/path/to/pacts/*.json' # optional, default value is 'spec/pacts/*.json'
task.pact_broker_base_url = "http://pact-broker"
task.tag_with_git_branch = true|false # Optional but STRONGLY RECOMMENDED as it will greatly assist with your pact workflow. Result will be merged with other specified task.tags
task.write_method = :merge # optional, this will merge the published pact into an existing pact rather than overwriting it if one exists. Not recommended, as it makes a mulch of the workflow on the broker.
