Pending pacts and can-i-deploy about pact-specification HOT 5 OPEN

I suppose a --allow-pending or something like that could be something for additional consideration. I'll move this to our feature request board, because it's separate to the specification itself.

from pact-specification.

It's a tricky situation. can-i-deploy is very much about telling you how reality works, whereas during development we have a bit more leeway. I suppose in this case, it is safe for the provider to deploy, because the provider already in the target environment (probably) doesn't work.

But, your consumer has broken the rules by ignoring this check. We could add more configuration/options, but it feels like it just makes the shooting of your feet more likely. This implies the tools have been circumvented, so you could collectively circumvent them again to resolve the situation.

This would be somewhat analogous to allowing you to regular git push after somebody else has git push --force a change to a repo. The --force was bad, and has now put the repo in a broken state, but allowing you to think things are normal by allowing regular options to keep working as is, is probably a bad idea.

from pact-specification.

Yeah I agree. We have some additional tests after the deployment we need and it is expected that every pacticipant can use one environment (test) and deploy and test ... let's say wildly ;). We include this environment in our can-i-deploy checks for faster feedback. I think this is our main issue at the moment. We do:
... deploy -> additional tests -> record-deployment -> can-i-deploy (everywhere)

We do it like that, because as said we need the deploy step on the test environment for the additional tests. This is why we did not put a can-i-deploy (test) infront of the deployment. Then it felt wrong not to include the record-deployment step afterwards. We were not sure where to include the can-i-deploy then. So we said ok at the end so that the teams still have the feedback from their tests etc. but also fast feedback from pact.

Maybe we can exclude test in can-i-deploy at the end, because as said we need to able to deploy there at any time and then maybe the can-i-deploy check makes no sense for this environment.

Or we can check if the usage of pending interactions can help us as well.

Nevertheless, I still want to ask regarding providing the information if a pact is pending or not also during the can-i-deploy step. Isn't that also a valid information, without changing anything regarding the can-i-deploy checks, but it provides us the info, ok somebody did something illegal or provides more flexibility for the different kinds of pipeline definitions?

Thx for the fast feedback btw.

from pact-specification.

We actually ran into something similar where because we have pending pacts and WIP turned on, junit essentially ignores the failures. The problem is that unless the dev is intimately familiar with pact, they assume that everything is ok and could potentially merge a PR that is actually not going to let them deploy.

Since the failure is essentially “hidden” by junit, a PR pipeline could still pass and be merged. Especially true if something like auto merge is turned on

from pact-specification.