• Is there any recommended limit of how many pacts one instance can handle? Multiple instances on the same database is feasible with no issues from reading the questions above. • Assuming the CI pushes the generated PACTs naively on each opened PR. How will the pact-broker behave when multiple PRs are raised in parallel on the same consumers. Having race conditions where all PRs are overrided with the latest one would be an issue? Would the matrix be mistagged in that case? People would need to retry each PR maybe? If that’s an issue, how do you usually mitigate this? • Loving consumer driven contracts, but small caviant I want to discuss: Since the provider verification tests run independently on the provider CI, writing a “bad pact” may result in a unesessary back and forth between people, especially if the provider is not “owned” by the same people working on the consumer. A clever hack I just thought of is to leverage the broker webhooks to run the Provider tests on the consumer CI as well. That ensures that a PR is merged only if this back and forth is resolved. Is there any downside i’m not seeing here? Is it common to do what I mentioned? • Regarding the deployments and environments, having multiple instances of the same version in different environments don’t need us to use the application instances flag right? Even if deployments are done on a rolling migration where you have canary/blue-green (instances with different versions temporarily). Ofc as long as we ask can-i-deploy before deploying and record a deployment once that’s done. The unique combination is service-enviornment-version, Anything missing here? • I’m tagging main with the application version (X.X.X.X) that I’m pushing to Octopus, I saw that the broker version PACTs differently, any way I can link both versions to know what version is on what environment? • Added my overall design flow, would appreciate any feedback and potential caveats I am missing here!

• Assuming the CI pushes the generated PACTs naively on each opened PR. How will the pact-broker behave when multiple PRs are raised in parallel on the same consumers. Having race conditions where all PRs are overrided with the latest one would be an issue? Would the matrix be mistagged in that case? People would need to retry each PR maybe? If that’s an issue, how do you usually mitigate this?

This is where using “latest” is not ideal. Race conditions aplenty. You should use the branches and environments tagging to properly disambiguate. TL;DR - each pact should publish the Git SHA as its version, the branch it’s associated with, and

record-deployment

when an app deploys. This usually sorts out most issues.

• Loving consumer driven contracts, but small caviant I want to discuss: Since the provider verification tests run independently on the provider CI, writing a “bad pact” may result in a unesessary back and forth between people, especially if the provider is not “owned” by the same people working on the consumer. A clever hack I just thought of is to leverage the broker webhooks to run the Provider tests on the consumer CI as well. That ensures that a PR is merged only if this back and forth is resolved. Is there any downside i’m not seeing here? Is it common to do what I mentioned?

Can you elaborate on this? I’m not sure I fully understand the workflow. In case it’s not obvious (it is hard to find in the docs) but if you publish the same pact twice, the second pact won’t need to be re-verified - it’s “pre-verified”. e.g. version 1 of the application publishes a pact, is then verified by the provider. Then you make some change to the application that doesn’t result in a contract modification, then than contract is pre-verified. Similarly, webhooks that fire are de-duplicated, to avoid multiple wasted builds.

You could also 1. Enable the webhook for the provider build, so when the pact is published the provider is verified 2. Then in your pipeline, run

can-i-deploy

with the

--wait-*

flags. This way, you can wait up to some configurable amount of time before failing the build if the result is false

• Regarding the deployments and environments, having multiple instances of the same version in different environments don’t need us to use the application instances flag right? Even if deployments are done on a rolling migration where you have canary/blue-green (instances with different versions temporarily). Ofc as long as we ask can-i-deploy before deploying and record a deployment once that’s done. The unique combination is service-enviornment-version, Anything missing here?

that’s correct

• I’m tagging main with the application version (X.X.X.X) that I’m pushing to Octopus, I saw that the broker version PACTs differently, any way I can link both versions to know what version is on what environment?

I think you’re asking can Pact Broker also store the underling SCM version, separate to the version we use? At the moment, no. One strategy is to include the git sha in the metadata of a semver version, that kind of gives you the best of both worlds. Not sure if that works in the X.X.X.X model though?

This is where using “latest” is not ideal. Race conditions aplenty. You should use the branches and environments tagging to properly disambiguate.

TL;DR - each pact should publish the Git SHA as its version, the branch it’s associated with, and

record-deployment

when an app deploys. This usually sorts out most issues.

Makes sense, so what the consumer/provider defines as a version is used to provide uniqueness. Git SHA is unique so it prevents any collisions in any case. My followup question would be doesn’t that infer a lot of cleanup afterwards or load on the broker? Each commit on a given PR modifying a PACT will be treated as a unique application version and all those will be pointing the the internal pact version. If the above is true, would something like

main_SHA-BranchName

as application version let: • Each PR raised being unique • While letting things get overriden on the same branch (since we only care about the last version) Or do you see potential race conditions or issues with this?

Makes sense, so what the consumer/provider defines as a version is used to provide uniqueness. Git SHA is unique so it prevents any collisions in any case.

yep!

My followup question would be doesn’t that infer a lot of cleanup afterwards or load on the broker? Each commit on a given PR modifying a PACT will be treated as a unique application version and all those will be pointing the the internal pact version.

Sort of. There is a cleanup process you can enable to take care of that: https://docs.pact.io/pact_broker/administration/maintenance