Hi all, PactFlow provides version control for contracts. CURRENTLY : Our CICD jobs have a dynamic variable for version that changes every time the job is run. But if we don't have any new changes in our contract, it is still showing as a new version in Pact Broker history since the version gets changed every time. The issue we are facing is : We do not want to publish new versions of contract when there are no changes. How can we publish the pact only when there is actual changes in the contract? FYI @John Joel

if a pact is published, and the contents have not changed, and the contents have already been verified an a previous version, the published pact with the new version will automatically be verified.

Our CICD jobs have a dynamic variable for version that changes every time the job is run.

It should only change, when your code changes. Are you suggesting you could retrigger the job, and it would publish with a new version number?

How can we publish the pact only when there is actual changes in the contract?

You would have to build tooling to pull down the contents of all verified contracts, check the contents of the pact file you have, against the contents of the remote pact files, and if there is a delta publish it. It doesn’t sound like you are using Pact in the intended way, and therefore seeing issues you are trying to solve problems for, that if you follow the recommended flow, you wouldn’t have

Just because your build number changes each time doesn't mean the version of your apps you publish to Pactflow should. Use the git sha and this problem will go away

Building a tool for that purpose was suggested by one of our team members as well but we thought to take a step back and ask here if there would be another way. We know that pact CICD jobs have arguments for versioning just wanted to know how it is supposed to be used dynamically in the correct manner. Will try git sha.

This article is going to be your best source to understand versioning in detail: https://docs.pact.io/getting_started/versioning_in_the_pact_broker

If you see the top 2 in matrix image below, we used $`CI_COMMIT_SHA` in our job. The contracts for the two versions published here are same. There was a commit made that did not change the contract itself. Still we see 2 versions here in matrix which is what I want to avoid every time we make a small change. Is $`CI_COMMIT_SHA` what you were going with @Matt (pactflow.io / pact-js / pact-go) when you suggested git sha?

why is having 2 entries a problem?

Every single change done by the team is causing a new pact to get published at Consumer side. Even when there is no change in the contract. We want to avoid that.

But why is it a problem?

Thinking about it, it isn't really a problem when this statement by Yousaf is true. "if a pact is published, and the contents have not changed, and the contents have already been verified an a previous version, the published pact with the new version will automatically be verified." If code changes, a new pact WILL be published. We will convey the same further. Thank you!

More importantly, we need to ensure each application version is modelled in PactFlow to allow other tooling to work (e.g. can I deploy)