Can i clarify the interactions for a consumer/provider CI/CD process. In the first PR for consumer would it always fail because the provider is not verified? The other question i have is about the purpose of webhooks for pactflow. How should i use them in the process? In my head im thinking First consumer PR run 1. Run the consumer pact tests 2. Publish to pact 3. Run can i deploy? (will fail because provider is not verified) but conversely if i try to deploy provider first without consumer run it will also fail because 1. Run the provider pact tests (nothing in broker cause consumer is not run and step will fail) So should it be ? 1. Run consumer pipeline (fail because provider not verified) 2. Run provider pipeline (pass) 3. Rerun consumer again and make it pass • Process seems quite lengthy and easy to "block" each other Please advice

Are you deploying as soon as you merge the PR? If yes, then your consumer PR run is right. However, you can improve it by running CI on push (but not PR) like this: 1. Run consumer pact tests 2. Publish to pact broker This means the contract might already be verified at the time of the PR

but conversely if i try to deploy provider first without consumer run it will also fail because

I think this depends. Personally, I think the consumer needs the provider, but the provider doesn't need the consumer. So, I would expect

can-i-deploy

for a provider with no verified consumers to pass.

understand so i guess i will only run "can i deploy" after merge and during pr/pushes , i will run step 1&2 (Run and Publish). Can you explain to me more about webhooks and purpose in pactflow. I still dont really get it

"can i deploy"

I would run can-I-deploy right before you deploy, whenever that is

Thanks. If you put the can i deploy to a separate job then if the whole process is continous delivery then would it then auto go to deployment even if that breaks?

Ideally no. Ideally a successful can-i-deploy is a prerequisite for a deployment

yeap. so just wanted to clarify what u meant by having a separate job. do u mean triggering it as a separate job but it is still blocking the deployment if it fails?

(also after a deployment, you need to tell the broker that you have deployed with

record-deployment

)

yeap. make sense

you don't need them to be separate jobs. I just like to reduce the layers of indirection in CI pipelines - if you put

can-i-deploy

as the first line in a job called

deploy

then sometimes you will get failures you're expecting

haha people will never be happy with broken builds... .

alternatively, and if your CI supports it, you might want to have a different status (skipped or blocked or whatever) when your

can-i-deploy

fails.

yeap gitlab that we are using should be able to support this easily

yes, because you need to tell

can-i-deploy

what you're asking about

so a consumer would have a unique pacticipant and a provider will also have one?

pacticipant is just a name for "consumer or provider". There have been some regrets about this naming choice

yeap find it a lil confusing but once explained its ok

For example:

pact-broker can-i-deploy /
    --pacticipant="$CONSUMER_NAME" /
    --version="$CONSUMER_VERSION"  /
    --to-environment=production

so environment supercede tags?

hmm, I'm not sure. I think the current recommended practice is to use environment instead of tags. I'd have a look in the docs

yea i think i read that somewhere

see https://docs.pact.io/pact_broker/recording_deployments_and_releases and https://docs.pact.io/pact_broker/tags

thanks.

You're welcome!

what are your thoughts of spring cloud contract versus PACT and are there any other alternative contract testing tool that is worth considering

I think someone did a comparison recently between SCC and Pact on youtube somewhere. I don't know SCC too well, but Pact has the substantial advantage that it supports several languages out of the box - so if you have a Spring consumer and a node provider, you can still use it

Yeap PACT has quite a lot of advantages compared to the rest and interestingly there are not many other competitors trying to provide contract testing solutions. In your opinion do you see any drawback / unsuitable scenarios in using contract testing

Sometimes people do "schema" or "spec" validation in place of contract testing (and worse, sometimes they call this contract testing) - I think this is dangerous, because you're not confirming whether your implementations actually understand each other, just that they produce messages that conform to the same grammar. A good example of why this is a problem is Chomsky's "Colourless green ideas sleep furiously" - it's grammatically correct english, but not understood to mean anything. See @Matt (pactflow.io / pact-js / pact-go)’s excellent blog post on this topic here: https://pactflow.io/blog/schemas-are-not-contracts/

Are there any example of using PACT with graphql?

In your opinion do you see any drawback / unsuitable scenarios in using contract testing

Currently (as you're experiencing) the effort required to understand it is high. Specifically consumer driven contract testing is not a good fit if you don't know who your consumers are (eg, for a public API). I think it's absolutely essential if you have any kind of complex architecture (eg, more than 2 services)

Thanks for all your help! Have a good weekend

🌮 for @Timothy Jones

🍻