Hi, I recently read that it is advised to change from tags to branches & deployed/released. Regarding Pact Nirvana I wonder what impact it has. I assume we now use the branch to publish pacts or validations on feature branches and mark the environment with the record-feature after successful deployment. Does it still hold true that we publish pacts only on PR validation and once they passed the verification and can-i-deploy (to environments) check we merge and instead of tagging main we set the stable branch (e.g. main) on the pact that was published during PR build?

Correct, depending on your PR merge setup, you may publish pacts from the main branch build as well, that would have a new version number but the same content, and would be pre-verified from the PR branch. (assuming the provider has verified the changed content pact on the feature branch, by way of webhook, or using WIP progress pacts on the providers regular CI build) Once is it deployed into an environment, you would record that version as deployed to x environment.

Hey Yousaf, thanks a lot 👍 - that answers a second question I had as well. One followup regarding the "pending-pact"-feature. I read that it is used in conjunction with tags. Is there a way to use it with maven JVM-plugin and branches? A colleague of mine pointed out an example where a change in a Consumer contract e.g. name of interaction state would cause the provider to need to change it and this would be a backwards incompatible change. We figured from reading the docs that a pending pact might help us here - however we are unsure on how to use it without tags.

pending pacts should work with branches without anything, bar adding enable pending into your provider lang. let me find some doccos

Much appreciated Yousaf 🙂 Thanks a lot! Guess you are making my day today!

Awww well if you can test it out and be my guinea pig, it would be much appreciated

Hey Yousaf,

the selectors pick pacts to verify and the provider build publishes results. you still want the can-i-deploy check to check the application, and specifically the application version, is compatible to be deployed into an environment, which will query the results performed by the provider verification

Ok, then I got it wrong. Thanks for clarification 🙂

I think I am following though, if a provider was to deploy that version of code, directly after doing a provider verification on their main build, they have verified all their pacts, the verification task will only fail if the provider made a regression (as enable pending is on) as there is a usually a delay even small in deploying services after running the verification build, we always advise running can-i-deploy directly before your deploy task, and record-deployment after. These might be different pipelines so best advising always use can-i-deploy 🙂

Hey Yousaf, sorry for bothering again. The following scenario: Consumer is changing an already existing PACT and changes the "given"-scenario on a feature branch. This would trigger provider verification on its stable version (we do not use web hooks) against the feature/branch and verification would fail. Now we look at the provider - in order to comply with the change a feature branch would be opened and the state would be renamed according to consumer requirements. This would mean we have a change that is no longer backwards compatible with consumer versions being on the stable branch e.g. master or the deployed version in production, but only the one on the feature branch of said consumer. In our case we would have a valid verification for both versions consumer and provider that are deployed in prod, we would have a failed verification of the feature branch of the consumer and the stable branch of the provider and we would have a successful verification of the feature of the consumer and the provider. Now this is where my question from earlier comes in: In the PR of the provider we would besides the verification also check whether we can deploy to production. In our case however, we do not have an entry in the matrix that would successfully verify production version of consumer to the new changed provider as the contract of production version and the verification (state was renamed) are no longer compatible and the PR would be blocked. Likewise the consumer can not merge his PR as the provider can not go ahead. From my understanding the pending-pact feature would allow to have the verification exit with a status code 0 and not fail the PR, however the can-i-deploy check would still block it? Now I wonder, did I get something wrong with pending pacts, is this scenario likely and are there ways around it?