hey there, I was wondering if there's some way aro...
# pactflow
m
hey there, I was wondering if there's some way around having to upload two contracts during a pipeline build, as our contracts are versioned with git commit sha. We need to upload 2, as when we merge to master it's a squash merge which switches the version to a new one, so if we were to not upload another contract on master, it would not find a contract with this new commit. Would like to not have to re-run tests to generate things another time, when the contracts are identical. Any thoughts appreciated!
b
Bit confused about the reasoning . . .
it would not find a contract with this new commit
Not sure what needs to find a contract in this description. But also, the tip of the branch isn't necessarily the same as the squashed commit (unless the branch is already rebased onto the trunk, or a few other scenarios).
As an aside, if the contracts are identical, the verification doesn't have to happen again, so it's only potentially wasting a test run on one side thinking2
(or if this is a BDCT thing, then I could be wrong. I'm much more familiar with CDCT)
m
hey, thanks for the responses! the need to find a contract is to ensure that the contract is verified on each environment the particular service passes through, as the checks are done per environment. Because the PR environments the latest commit is different from the lastest master commit (because of that squash merge), the first check in the first environment on the master branch does not find the contract to do the verification checks (i.e. recordDeployment in the first prod env and canIDeploy to the next prod env). Hope that makes more sense? We get around this currently by deploying the contract again with the newest commit (that squash merge) as the version
b
That sounds like you're manually finding the things to test/verify, instead of using webhooks? Or am I misinterpreting? What does your overall workflow look like?
m
yes no webhooks in bidirectional contracts, it's just uploading contracts from consumers and publishing OAS for providers, then calling canIDeploy with the pacticipant name, version and destination environment, and that is called before deploying to each environment
b
oh right, so it is BDCT. I can't help with that, really (sorry!), hopefully one of the maintainers can 🙏
m
no worries, thanks a bunch for your input anyway!
👍 1
j
Hi @Milda did you figure out a solution to this? Currently encountering the same thing.
m
Hi Jordan, unfortunately no luck so far, we just upload it twice, on for PR and one for the master build 🤷‍♀️
m
Yeah it’s tricky, because the thing you deploy is the application version, and to know if it’s safe to release that we need an association to a contract. maybe there is a way we could allow that association to be added without re-creating the contract? For my help, is this step slow for you? I’m imagining it’s just running the publish command, so shouldn’t take more than 30s I wouldn’t think?
m
I think it's a case of having to re-run the generation of the contract potentially, depending on how the pipeline is set up, which does add some extra time
👍 1
hey quick one here if it's of use to anyone, our way around this was to: 1. tag the contract with the git sha version in PR 2. use
gh
to retrieve the last PR before squash & merge 3. use pact to get the contract version via the PR tag 4. tag the contract with the semantic version for future use
nice 7771 1
m
Thanks for sharing!
👍 1