You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the provider side, the pacts can be verified using two strategies. The external strategy only runs pacts against the ones specified in the pact.sbt file through providerName and consumerNames attributes. However, the internal strategy happily runs all the pact spec files, no matter what provider they might have. This can be misleading.
I think we should either:
make the pact-filtering consistent across the two strategies so that pact:sbt skips the pact verification spec files with consumers other than the one specified in pact.sbt. Personally, I am not in favor of this, as we already have ignore in spec files which allows us to ignore spec files. Having that ability in two places, can be problematic.
We could nest providerNameconsumerNames and pactBrokerAddress information in the pact file, as parameters to a pactVerify field or something like that. It might also be a good idea to make the name more specific as one might get the impression that this information is also used for consumer-side pacts. so maybe something like: pactExternalVerify. We could also consider advocating the convention of naming pact.sbt -> pactVerify.sbt or pactExternalVerify.sbt.
The text was updated successfully, but these errors were encountered:
In the provider side, the pacts can be verified using two strategies. The external strategy only runs pacts against the ones specified in the
pact.sbt
file throughproviderName
andconsumerNames
attributes. However, the internal strategy happily runs all the pact spec files, no matter what provider they might have. This can be misleading.I think we should either:
make the pact-filtering consistent across the two strategies so that
pact:sbt
skips the pact verification spec files with consumers other than the one specified inpact.sbt
. Personally, I am not in favor of this, as we already haveignore
in spec files which allows us to ignore spec files. Having that ability in two places, can be problematic.We could nest
providerName
consumerNames
andpactBrokerAddress
information in the pact file, as parameters to apactVerify
field or something like that. It might also be a good idea to make the name more specific as one might get the impression that this information is also used for consumer-side pacts. so maybe something like:pactExternalVerify
. We could also consider advocating the convention of namingpact.sbt
->pactVerify.sbt
orpactExternalVerify.sbt
.The text was updated successfully, but these errors were encountered: