pact-foundation/pact_broker-client

can-i-deploy fails if no pact was published by pacticipant

Closed this issue · 9 comments

jawu commented

I would expect that the can-i-deploy function returns non-zero exit code

  • if one or more pacts where published by the given pacticipant
  • AND these pacts were not successfully verified

I would expect that the can-i-deploy function returns zero exit code

  • if all published pacts of the pacticipant were successfully verified
  • OR if there are no published pacts

The current implementation returns non-zero exit code if there are no published pacts by the pacticipant.
That stops services from getting deployed, because they have no providers.

bethesque commented

Interesting. Can you explain your usecase a bit further? Is this because you have a generic deploy script, and some applications use pact, and some don't?

My main concern with this is that it might hide some errors - for example, someone might disable the pact publishing accidentally/temporarily/on a branch, and then this check ceases to be useful. Perhaps there is another function we could add to the command line that would let you do something like if not pact-broker describe-pacticipant Foo OR can-i-deploy --pacticipant Foo

jawu commented

We try to have generic deploy scripts/pipelines for nearly every service. Especially in this phase when we introduce pact into our platform, most services do not have pacts published and the can-i-deploy command fails. If we introduce a new service, that do not have any dependencies and therefore has no pacts to publish, the command fails.
Maybe there could be a flag --pass-with-no-pacts which defaults to false?

bethesque commented

Righto, let me think about it.

bethesque commented

Sorry, I've gotten caught up with other things, ping me on this in a few days.

bethesque commented

So, I've been meaning to add a pact-broker describe-pacticipant to the CLI that will let you check if the application actually exists in the broker before you do the can-i-deploy. This will get rid of your false negatives. I've sworn not to do any dev on anything else until I've got Ruby pact-message out, so in the meantime, you could check if the pacticipant exists by doing a curl $PACT_BROKER_BASE_URL/pacticipants/$APPLICATION_NAME

I have been considering adding an --ignore $DEPENDENCY_NAME as an option so that if you know that one particular project hasn't gotten to implementing verifications yet, you can still use the script. I've added the feature description here: #28

mellowplace commented

I too find this behaviour strange. I’m not sure if my pipeline design is not best practice or if can-i-deploy is wrong.

My usecase is that I have a github flow, continuously deployed, pipeline for a provider. When a PR is raised I want to verify I can deploy the provider against all consumer pacts tagged production.

My provider pipeline also verifies pacts for consumers. When it’s CI is triggered via the broker web-hook, a single stage runs on the master branch to verify the newly published pact.

Because of the current behaviour of can-I-deploy I cannot get a brand new provider PR to be merged onto master so it is then able to validate individually published pacts.

TLDR it’s a chicken and the egg problem :-)

bethesque commented

How old is your broker @mellowplace? Are you having this problem? #48 This is fixed in the latest version.

bethesque commented

Closing due to inactivity.

rafael-anachoreta commented

Hey @bethesque , I think this issue still exists in the latest version of the pact broker client (1.58.0) and would like to reopen it.
Here is my use case and potential steps to reproduce:

  • I have a Consumer A that has contracts with several other Providers (X, Y, ...).
  • I decide to add a new contract between Consumer A and a new Provider Z. I publish the contract and verification results between them to the broker.
  • For whatever reason, I then decide this new pacticipant pair is no good, so I delete all the published pacts between them.
  • I run can-i-deploy for either Consumer A or Provider Z and I now get
There is no verified pact between the latest version of Consumer A with tag production (my-git-sha) and version my-version of Provider Z

It's also worth noting that since Consumer A and Provider Z have other interactions, I can't just delete the entire pacticipants individually.
If I go to /pacts/provider/Provider%20Z/consumer/Consumer%20A/versions, I can see that there are no pacts published and have even tried to send a DELETE to this endpoint, but the pair itself is not deleted, just the contracts.

This prevents me from using can-i-deploy now. Is that intended?

Edit: following the suggestion from @mefellows I was able to delete the integration itself and temporarily work around the issue.