Build passes when provider is removed

We are facing an issue in our pipelines when removing a Provider java class, as it stands we should be validating that the consumers are not affected when the provider is deleted or changed. But the pipeline is passing. At the moment, we are creating a branch where we remove Provider classes, expecting the pipeline to fail when tested with all current consumers. To run the pipeline we are using a multiple step approach, starting with a mvn call with the following mvn arguments

mvn -B -Dpactbroker.consumerversionselectors.tags=master -Dpactbroker.providerTags=master -Dpactbroker.host=${PACT_BROKER_HOST} -Dpactbroker.auth.token=${PACT_BROKER_TOKEN} -Dpact.verifier.publishResults=true -Dpact.provider.version=$PACT_PROJECT_VERSION -Dpact.provider.tag=$BITBUCKET_BRANCH verify

In the logs we are able to see that we are checking against the consumers, but the following appears

Not all of the 6 were verified. The following were missing:

xxxxCommand

yyyyCommand

But it still passes. And a second step where we call can-i-deploy in a docker command

mvn pact:publish -Dpact.broker.token=$PACT_BROKER_TOKEN -Dpact.broker.url=https://$PACT_BROKER_HOST -Dpact.projectVersion=$PACT_PROJECT_VERSION -Dpact.consumer.tags=$BITBUCKET_BRANCH
docker run --rm -v ${PWD}:${PWD} -e PACT_BROKER_BASE_URL=https://$PACT_BROKER_HOST -e $PACT_BROKER_TOKEN pactfoundation/pact-cli:latest broker can-i-deploy --broker-base-url $PACT_BROKER_HOST --broker-token $PACT_BROKER_TOKEN --pacticipant ${BITBUCKET_REPO_SLUG} --version $PACT_PROJECT_VERSION --to master --retry-while-unknown 60 --retry-interval 10

I assume that the first step of the pipeline, the maven call, should fail as the contract will be broken.

• Are we wrongly configuring pact? We have filtering enabled.

[mefellows]

OK so this makes a bit more sense.

Note the warning:

Unless I’m mistaken about a JVM specific feature, filtering is intended for isolating one or more tests for dev reasons. It’s not designed for integrating back to the broker, because it wouldn’t receive a transactional, binary true/false response, to be able to determine compatibility etc.

This also explains why your contracts are pending, because verification results haven’t been published to prove you’re compatible. The contract is still pending, regardless of whether or not it can satisfy the needs of the consumer.

So your can-i-deploy still works, presumably, because as far as its concerned, your provider hasn’t changed and the version that works still satisfies the contract.

[mefellows]

Good to hear (and thank goodness) - thanks for clarifying @mcarn .