A passing provider build does not automatically mean a new consumer or provider version is safe for production. can-i-deploy is a Pact Broker CLI command that queries recorded contract verification results and deployment information before allowing a version to proceed. It acts as a deployment safety gate for consumer and provider changes. section 3.4 section 10.2.5
The command checks whether the version about to deploy has successful contract verification results with versions already deployed to the target environment. This matters when production lags behind the main branch: compatibility must be checked against what is actually running, not merely against the latest code. section 10.2.5 section 10.5
A typical contract-testing deployment flow is:
- Generate a consumer contract and publish it to the Pact Broker with version metadata. section 1.5.1 section 3.5
- Have the provider retrieve and verify the contract, then publish the verification result. section 3.5
- Record deployed or released versions for each environment so the broker can identify the production baseline. section 10.2.4 section 10.5
- Run can-i-deploy for the consumer or provider version before merging or deploying; proceed only when the compatibility query succeeds. section 6.1.3 section 10.2.5
Gate a production deployment
A WebConsumer and MoviesAPI pipeline can run `pact-broker can-i-deploy --pacticipant WebConsumer --version=$GITHUB_SHA --to-environment production`, with an analogous command for MoviesAPI. The command checks the named version against relevant versions deployed to production. In the illustrated matrix, consumer version 13 can deploy alongside production provider version 42, while consumer version 14 cannot because its verification failed. section 10.2.5 section 10.2.5
Table 10.1 How can-i-deploy works
|
Consumer Version
|
Provider Version
|
Verification Status
|
|---|---|---|
|
12
|
40
|
Failed
|
|
13
|
41
|
Failed
|
|
13
|
42 (production)
|
Passed
|
|
14
|
42 (production)
|
Failed
|
Use the matrix example to see why a version with a failed verification is blocked even when another consumer version is compatible with the production provider. section 10.2.5
Treat an unknown result differently from a failed result. Unknown can occur when provider verification is still running; `--retry-while-unknown=<NUM>` retries the query for a chosen number of attempts. A real mismatch still blocks the pipeline, such as a consumer changing an expected HTTP status from 200 to 201 while the production provider returns 200. section 10.4.4 section 10.4.5
can-i-deploy complements contract tests rather than replacing them. Consumer tests create expectations, provider tests verify them, and the broker stores the versioned results. The command turns those results, branches, and environment records into a release decision for the specific version being deployed. section 3.5 section 9.1.1
