I've encountered a CI/CD design blocker that I can't seem to get around: I was planning to create a pact on every commit, use the commit sha as the consumer version, and the branch committed in, as the consumer branch. I was planning to use github statuses to report whether a commit is compatible with the API, where, once the provider publishes the test result, a webhook will be triggered to change the consumer commit status in accordance with the test result. Now this causes this issue to arise: If a branch commit produces the same pact as the previous commit, how do we get the status of the new commit to be the same as the previous one, without having the provider test every single pact that is published? 'Branch Commit' meaning a commit with the branch set as XYZ on Pactflow. We are assuming we are committing on the same branch in these scenarios. I initially thought, that you could set a webhook on pactflow to be triggered when a duplicate pact is published, but that's not an option in the webhooks. So basically I have no idea how to get around this issue.

Not sure if this helps or not, but if you commit the pact file itself you could trigger your workflows only when the pact file changes. This would have problems with your version numbering scheme though because getting the hash of the commit that created the pact is one thing, then committing the pact file itself would have a different hash.

If the contract is identical to one previously verified, then the broker knows that it doesn't need re-verification