can-i-deploy --to=TAG fails if there's no participant version with such tag

[ghost]

Hi!
We want to use the recommended approach for pact testing (we don't have CD) with can-i-deploy --to=TAG command.
When a consumer publishes new pact, it is tagged with the name of a feature branch and verified by provider.
After successful deployment it is tagged with the name of the stage.

So before deploy to production we want to use command:
./pact-broker can-i-deploy -a backend-catalog -e eaae34f4 --to prod

But we face the following problem.
If there is some participant which doesn't yet have participant version tagged with "prod" this command fails.
It returns:

{"error":{"message":"No version of UI-xxx found with tag prod"}}
script returned exit code 1

Does this really should fail?
This means that every new consumer which publishes new pact with tag different from somehow expected to have prod version at once.
But how it can be achieved?
The first step is consumer publish pact and provider verifies it.
And only after provider deploys version which will verify this pact - consumer version will be deployed and tagged as "prod". But provider can't deploy its version because of the error.

We expect that this command will not fail if there is no version with some tag for some participant.

[bethesque]

If you know it's compatible, run the first deployment without the can-i-deploy check. Then, when each of them have a version in production, tag those versions as prod and you should be fine to run your can-i-deploy --to prod thereafter.

[ghost]

Thanks for answering my question so quickly.
Yes, it may be ok for the first deployment.
But we plan that other consumers will join this process in the future and it means that we will be forced to turn off the "can-i-deploy" again, until new consumer will be deployed.
That can be for a long period of time. And we will not have an opportunity to use benefits of contract testing with this command.
If some consumer doesn't have a version with tag it shouldn't be checked and fail deployment.

Isn't it a gap which should be fixed?

[bethesque]

Are you using test environments? Typically, you would tag each version with the stage name of each environment (eg. test, prod) and use can-i-deploy --to test to deploy to your test environment first, or just can-i-deploy --pacticipant Foo --latest (which checks if the latest versions of each are compatible) if you didn't use any tags (not recommended though). If you went straight from master to prod, you could tag all your pacts with the branch names (this is recommended) and do can-i-deploy --pacticipant Foo --latest master

Have you read this? https://docs.pact.io/best_practices/pact_nirvana

[ghost]

Yes, we are using test environments and I've read this article but it doesn't solve our problem.
We agreed to tag our pacts with the stage name and to use can-i-deploy --to TAG before deploying to any test environment or prod.

And with this approach we have such situation when a new consumer wants to use provider API and publishes new pact and tags it as test, provider is no longer able to deploy to prod because new consumer didn't tag its version still and can-i-deploy --to TAG fails.
But why new consumer should fail deploy provider to prod? This consumer is not a production consumer yet.

[bethesque]

It does make sense that you should be able to deploy a provider with a missing consumer, but not the other way around. I'll have a look and see if I can add this logic.

I've been meaning to add an --allow-missing-dependency option for a while, but just haven't had time.

In the meantime, if you explicitly list the names of the apps your provider integrates with, it will just check those apps, and not do an automatic calculation.

[bethesque]

I'm working on this, but it's turned out to be more complex than expected! It will be in the next release.

[ghost]

Thanks a lot!

[bethesque]

Please upgrade to 2.29.0 (docker tag 2.29.0-1) and retest. Let me know how you go.

[ghost]

The issue works correctly for us now. Thanks a lot

[bethesque]

Great! Thanks for persisting with this. It's a problem I'm glad to have fixed. I hadn't fully understood the implications of it until you kept explaining.