wave Hello Question about pact cli `can i deploy` Is it pos Pact Foundation #general

:wave: , Hello! Question about pact cli `can-i-dep...

Vittorio Guerriero

12/28/2022, 4:34 PM

👋 , Hello! Question about pact cli

can-i-deploy

Is it possible to specify the version of a Pacticipant through the environment? Basically we would like to do this

Copy code

pact-broker can-i-deploy --pacticipant AConsumer --version ${gitHash} --pacticipant AProvider --environment prod

This should only check for the Provider version with the environment prod. We are currently using pact-node and I couldn’t find a way to do this

Vittorio Guerriero

12/28/2022, 4:36 PM

We would like this functionality because we trigger the verification process synchronously only for the

can-i-deploy

that fails.

Vittorio Guerriero

12/28/2022, 4:37 PM

This is the version I am using

Copy code

"@pact-foundation/pact-node": "10.17.2",

Vittorio Guerriero

12/28/2022, 4:41 PM

Just to clarify that we cannot use

--to-environment

because this would include all the Providers in this instance. We would like to specify a single pacticipant with another single pacticipant. Let me know which other info you need!

Timothy Jones

12/28/2022, 9:03 PM

Can you use

pact-core

instead of pact-node? It’s the core that backs pact-js@10 and above

Timothy Jones

12/28/2022, 10:02 PM

Just to clarify that we cannot use --to-environment because this would include all the Providers in this instance.

We would like to specify a single pacticipant with another single pacticipant. What is the reason that this is a problem? The use-case for

--to-environment

is to see if it is safe to deploy the application (ie, including all of its dependencies)

Vittorio Guerriero

12/29/2022, 7:26 AM

Morning here! 🌅 ! Thank you for your answer

Can you use
pact-core
instead of pact-node? It’s the core that backs pact-js@10 and above

I can certainly do! I was using pact-node because I was simply running the commands from a shell rather than creating a javascript script. Is there a specific reason why is recommended over pact-node?

We would like to specify a single pacticipant with another single pacticipant.

Basically, we are following an approach without webhook at Cazoo, As part of the consumer pipeline we • run the tests • publish the pacts • run can-i-deploy -> this is the one that I would like to change • run the verification only if the previous can-i-deploy failed • …. This gives us the advantage that we have an immediate response from the Provider if the verification failed or succeeded. The need of using can-i-deploy with a single Consumer and Provider is to control which verifications we want to trigger. Example ConsumerA is consuming different APIs from 2 different Provider. ProviderA and ProviderB. ConsumerA make a change to the pact that is compatible with ProviderB and it does not affect ProviderA ConsumerA will publish the pacts ConsumerA will run can-i-deploy, it will fail for ProviderB but it will succeed for ProviderA ConsumerA will run the verification on the ProviderB but not the ProviderA

Vittorio Guerriero

12/29/2022, 7:26 AM

@anto FYI

anto

12/29/2022, 8:09 AM

Just to clarify further, we’re implanting a webhook-less flow and Beth pointed me to this but we’ve been unable to use the command successfully.

Timothy Jones

12/29/2022, 9:04 AM

Is there a specific reason why is recommended over pact-node?

Yes, the latest version of the binaries are in pact-core. Pact-node was renamed

pact-core

to reduce confusion (it was a core package without a convenient DSL that sometimes people mistook for the package to use if you were doing server side node). 9.x depends on pact-node, while 10.x uses pact-core.

Timothy Jones

12/29/2022, 9:19 AM

I’m not sure I fully understand the workflow you describe, but I have only had time to skim read it so far (I’ll be able to check back later). My first impression is that the situation you describe doesn’t need to be able to drop providers from the query. But perhaps I am missing something

Timothy Jones

12/29/2022, 10:32 AM

Ok, I think I understand your use case. Are you saying that you want to use can-i-deploy to determine which providers are failing (if any) and then immediately run their verification steps? If yes, what I would do is use the json output from can-i-deploy (there’s a flag for it), parse it, and use that output. This is better than running individual can-i-deploys because it means that you can use the environment selectors and won’t miss any providers.

Timothy Jones

12/29/2022, 10:35 AM

I’ve never tried running the provider verification in the same build - it feels like it might be more trouble than its worth, but also if this works for you I can’t see anything wrong with it. I’d be keen to hear how you get on

Timothy Jones

12/29/2022, 10:38 AM

Without webhooks, I usually just go: Consumer build: • build / test • publish pact Consumer deploy (triggered after build) • can-i-deploy • deploy Provider build • build / test • verify pact(s) • publish results Provider deploy (triggered after build) • can-i-deploy • deploy This has the disadvantage that sometimes changes need to wait for the other thing to be triggered by changes (costing unnecessary waiting time). Sometimes I have kicked them off manually (costing time and mucking about), or had the provider build trigger after the consumer build (costing unnecessary builds, and additional complexity).

Timothy Jones

12/29/2022, 10:39 AM

If you do them all in the same CI session, then the wrong project might fail the build, which could be annoying

anto

12/29/2022, 11:01 AM

@Timothy Jones I’ve implemented the workflow Vittorio is talking about before - I talked about it in the first community event we ran 2 years ago.

Timothy Jones

12/29/2022, 11:05 AM

Oh! Haha! I thought I recognised the name. Forgive me, I’m very tired 😅

Timothy Jones

12/29/2022, 11:06 AM

I remember being impressed by your talk

Timothy Jones

12/29/2022, 11:07 AM

https://www.youtube.com/watch?v=wkld_wRsTDE&t=1596s▾

Timothy Jones

12/29/2022, 11:09 AM

At 11749 it looks like you also used the json output of can-i-deploy, too

Timothy Jones

12/29/2022, 11:10 AM

Could you say more about what’s not working this time?

Timothy Jones

12/29/2022, 11:15 AM

Following the docs here, I think this:

Copy code

pact-broker can-i-deploy --pacticipant AConsumer --version ${gitHash} --pacticipant AProvider --environment prod

should have

--to-environment

not

--environment

, yes?

Timothy Jones

12/29/2022, 11:17 AM

The docs also say:

If you declare two (or more) application versions as well as a --to ENVIRONMENT, then the Pact Broker will work out what integrations your declared applications will have in that environment when determining if it safe to deploy.

So, I think you’d need a version for

AProvider

(even if it is just

--latest

)

Timothy Jones

12/29/2022, 11:21 AM

Hmm. Maybe this doesn’t actually do what you want. I think it is asking if it’s safe to deploy all of those things to production, not selecting the versions of those things in production.

Timothy Jones

12/29/2022, 11:31 AM

Maybe you can use

--ignore

anto

12/29/2022, 11:36 AM

I had to parse the response if I’m not wrong. But @Beth (pactflow.io/Pact Broker/pact-ruby) has implemented a more straightforward command. And we were using tags.

anto

01/11/2023, 11:07 AM

Solved. Here is the command we needed:

Copy code

pact-broker can-i-deploy --pacticipant=a_consumer --version=consumer_version --pacticipant=a_provider --latest --in_environment=Prod -b=broker_url -k=a_token

🎉 1

anto

01/12/2023, 7:46 AM

Any thoughts on this? It should be a simple change but I’m not sure if it would be formally correct to have the provider version in the response. However it would save us from having to use the api to get the id for the environment and then get the latest prod version for the provider from the list of “latest”.

2 Views

Open in Slack

Previous Next