Hello, hoping someone can help me with

record-deployment

and

record-release

please... When I

record-deployment

into an environment, should the

--version

be the same git commit sha for each environment I deploy to? Reason I ask is because I had a command like this

docker run pactfoundation/pact-cli:latest pact-broker record-release --pacticipant DojoPayConsumerApp \
--version $BITRISE_GIT_COMMIT \
--environment production \
--broker-base-url $PACT_BROKER_BASE_URL \
--broker-username $PACT_BROKER_BASIC_AUTH_USERNAME \
--broker-password $PACT_BROKER_BASIC_AUTH_PASSWORD

in CI for deployments and releases, where the

$BITRISE_GIT_COMMIT

version would be different for each deployment. On the

record-release

I was getting failures as it could not find the version it was looking up, would love some clarification on this please, thanks 🙂

I'm also a bit of a pact newbie, but I think you should be re-using the same version for every environment. When you cut a release of your service in git (whether you use tags or release branches), there should be one commit sha representing the release-tagged commit or the latest commit on the release branch. In either case, that is the commit sha you want to use as your version in pact because that value won't change as you deploy your service to different environments.

Thanks, this is what I’m thinking I need to switch to and where I made a mistake.

$BITRISE_GIT_COMMIT

was different for each environment probably based on our git flow and how Bitrise works. That env var is provided by Bitrise and auto grabs the commit sha. When I make a PR, that will be one commit sha, when the job is triggered to merge that into develop branch, that’s another commit sha etc etc. I’m guessing what I need to do is make sha consistent across all record deployments and releases, but would love some confirmation, if maybe @Matt (pactflow.io / pact-js / pact-go) knows please?

Oh, your commit sha is always going to be different between your PR branch and your develop branch, because when you merge, the merge commit itself will be your latest commit, and that will have a different sha. What I did in this situation was to simply (on the consumer side) re-generate and publish the contract after merging, and (on the provider side) re-run the verification after merging so that the latest commit sha is included and verified in the pact broker

right but then on that pr merge i do one

record-deployment

then later down the line might do other

record-deployments

to other environments, should the sha be the same for all those

record-deployments

?

I'd guess that when you call

record-deployment

you should always use the actual commit sha that you deployed, or else the

can-i-deploy

feature won't really work as intended.

hm, so the main issue I have is by the time I get to

record-release

its trying to use a git sha version it cannot find, e.g. another different sha

Right, the error you're getting looks like the pact broker has never seen that sha before

correct, so im wondering does it need to be the latest version / sha from a specific tag/environment for

record-release

?

if your pacticipant is a consumer, make sure you upload its contract file with that sha as a version number before you call

record-release

yep i do 👍

and if your pacticipant is a provider, make sure you verify it with that same sha

Im on consumer side, I’m thinking for

record-release

I probably need to grab the sha/version for the latest consumer version with the

preproduction

tag/environment (which is the last environment before

production

so to address your question specifically:

does it need to be the latest version / sha from a specific tag/environment

I'd say no, it doesn't need to be the latest, but it sounds like it does need to be a version that the pact broker has seen before

hm i get what ur saying, i will dig into whats going on some more and come back on this issue, thanks

Maybe the real pact folk can give you more ideas too. As I said, I'm just a newbie myself. But I think they are all on European time, so you probably won't hear back from them for a bit. Hopefully I could help get you unblocked in the meantime 🙂

im uk based, think they are on australian time

Ah, that sounds right

alright ive spotted the issue. in our job that records the release (

trigger_master

) we dont run any unit tests etc thus the

pactPublish

never happens so it cant find it 🙃

🌮 for @json - thanks for your help!

@Thomas K This is one of the reasons it's a good idea to have completely repeatable version numbers for a given commit - that way it doesn't matter if the contract isn't published as part of your release, because the pre-release pipelines have already done it

@Timothy Jones thanks, i guess this was partly a question i had, do i run pact tests and

pactPublish

in my release pipeline and the just auto grab the commit sha for that? Or do i instead grab the commit sha from my pre-release pipeline and use that when recording a release in my release pipeline?

Why are they different?

they are different because they are different jobs

trigger_master_pr

and

trigger_master

Also, this whole situation was the motivation behind this:

(i use commit sha, it auto grabbed from bitrise ci, so it changes for each job i think)

Commit sha will be the same unless your jobs are committing stuff

so we use git flow rather than trunk based dev on consumer side, so when we trigger a pr merge into a release branch or something, the sha changes

Yeah, that bit makes sense, the merge commit itself is a commit and will have a new sha, so I think you just need to be uploading the contract or running the verification more often. In my pipeline, since we're doing trunk-based development, we upload the new contract file for both the PR branch and the master branch. In your case since you're doing gitflow, you'll want to upload a new contract file even more often than that. Essentially any branch that will have unique commits on it, including: • Your feature branches • Your develop branch (because of the merge commits) • Your release branches (probably, though in theory you might not, since creating a branch doesn't create a new commit sha, in practice you will generally need to merge bug fixes into your release branch, and as mentioned above, merge commits create a unique sha) • Your master branch (again because of merge commits, but it would also probably be useful to tag these pacts with the master version numbers) • Your hotfix branches (like feature branches, you probably want to verify contracts before you allow merges, but since it's a hotfix, you may want to build in a way to override for emergencies)

thanks, we actually do seem to use unique commits this often, except for this specific case where we merge into master after a release is published