Hi. I am trying to upgrade our flow from tags to c...
# general
k
Hi. I am trying to upgrade our flow from tags to contract selectors and I stumbled upon chicken or an egg problem that was already there but I hoped that contract selector will solve it. I have working process for https://docs.pact.io/pact_nirvana/step_7 but how should I handle the first time when I publish new contract between two services? I have two repositories with branch
feature/abc
containing first contract between two services. I cannot merge consumer as it will fail
can-i-deploy
(provider supporting contract is not yet deployed on target environment). If I merge provider it won't record deployment as contract selector looks for main branch and release/deployed pacts. Pending pacts and WIP pacts won't help as this contract was already verified from branch so selector returns no contracts when run from main branch after merge, it won't fail build just because the annotation
@IgnoreNoPactsToVerify
. It seems that I have to manually verify against branch
feature/abc
, rerun deployment pipeline to register deployment and then I can start merging consumer. Is there any valid way to do that without the need to manually running verification or hardcoding branch
feature/abc
in the selector? Did I miss something?
u
say your consumer’s branch
feature/abc
implements consuming data from a new endpoint. What’s the danger in rolling out (and recording the act) of your provider’s branch
feature/abc
assuming that it doesn’t break contracts of already rolled out consumers?
I personally would solve the chicken-egg problem by rolling out the provider first. Always.
the dynamics completely change when you have breaking changes in
feature/abc
in both sides. That’s a trickier problem, and my general reaction is “don’t introduce breaking changes”
k
Thr problem is that typically you would use commit id to calculate pacticipant version. Merge to main branch (release) creates new merge commit. If you implement version selector as documented CI after merge will search for contract that was: • Released to any of the environments • Main branch of consumer Which will return nothing as the only place where the contract exists is still branch
feature/abc
of the consumer. So verification will verify against zero contracts so provider version won't be registered in pact broker. Therefore you cannot register deployment of this version as it was never created in the pact broker.
u
oh, this is a new provider then?
k
Yes
u
right, and the provider exists in the broker already?
my question is: if the provider exists as a thing in the broker, and can’t verify anything, should you be able to roll it out?
k
You have to record provider deployment first as if you followed the pact nirvana (https://docs.pact.io/pact_nirvana/step_7#add-can-i-deploy-to-environments-to-your-pr-pipelines) then you won't be able to even merge consumer due to can-I-deployment failing.
u
how so? IIUC if you roll out the provider with branch
feature/abs
, and you record the rollout, then the consumer should be able to roll out as well (branch
feature/abc
), no?
k
I do not have rollout from feature branches only from main branch where matching by branch name won't work.
The only possible piece of code that might get this to work is this note: https://docs.pact.io/pact_nirvana/notes_1
u
right, I see, interesting. We might actually be running into the same problem: new provider (we’re the consumer), and the provider can’t find our contracts for some reason. They’ve never rolled out, etc.