Hi, what is the recommended way to publish pacts in a CI-pipeline? Publish a pact during development on a feature-branch or should it only be published once the PR is initiated? kind regards

I publish on every commit, and also at PR time, (where PR is rebased from master/main), that gives me the quickest feedback as a consumer, as each of these will trigger pact verification jobs. If the pact content hasn't changed it will be pre-verified, if the pact content changes, people are made aware and it can be verified on the commit or PR time. Some may choose to only do it at PR time, thats fine, there is no right answer just a recommended one. Our CI/CD workshop publishes on every commit

Thank you Yousaf. 👍

@Yousaf Nabi (pactflow.io) Thanks for the reply. In your way (publish on every commit), there's high chance to have flooding pacts on pactflow. is there a way provided to automatically clean up old pacts?

I would expect that not to be the case, what is your throughput of commits? Provider verifications are only triggered if the Pact content changes, but the broker determines this, so it requires the contract from a known point in time, denoted by a version number (which we often use as a commit sha, because of its point in time guarantees) We got asked this question recently, here was @Matt (pactflow.io / pact-js / pact-go)'s answers

How many contracts can PactFlow handle?

The load/performance characteristics of the system are correlated to number of contracts, but it’s not the only factor. We have many customers on hundreds of contracts without performance related issues.

Is there a way to clean up the environment and remove old contract testing information?

We run data cleaning on all tenants, documentation for this will actually be published soon. See https://docs.pact.io/pact_broker/administration/maintenance#recommended-starting-configuration-for-keep-selectors for a bit more information on the process, the exact values may be tuned by Pactflow based on performance, load and other characteristics.