I've read articles like this one that suggest verifying contracts on the provider side that exist in a consumer's feature branch, in effect allowing the contract to be "pre-verified" before being merged to master. However, I've read other documentation from the Pact team stating the opposite. In The Steps to Reaching Pact Nirvana, it states "To keep a green build in your provider’s CI, rather than verifying the latest overall pact, it should verify the pact for the latest version tagged with “master” in the CI." Here, I'm assuming the words "latest overall pact" mean the pact that might exist in a consumer's feature branch that was published to the Pact Broker.
I'm confused. So as to not "make provider teams unhappy" as stated in The Steps to Reaching Pact Nirvana, what would be the purpose of ever publishing a pact from a consumer's feature branch if the provider would never verify that pact and only verify "master" and "production" pacts? Another way to ask this is when would/should pacts ever be published/verified from feature branches and solely not the master branches of consumers and providers against the "master" and "production" pacts?
Just noting that this is the latest guide on "effective Pact setup": https://docs.pact.io/best_practices/pact_nirvana. Hopefully this is clearer.
But in case it's not, pre-verifying feature branches is definitely a core feature of the Broker and something we would want to do. Once a change is in master, in 99% of the cases it should be smooth sailing (i.e. compatible). It's standard practice to either a) have a webhook that can trigger the pact verification step of a provider build to verify the new feature or b) have the corresponding feature branch in the provider verify the pact in CI when a change is pushed.
There is also a new feature coming out soon called "pending pacts", which will improve this situation drastically too, effectively allowing any new contracts to not break a providers' build, but still providing feedback to consumers if the change is supported.