Treat Contracts as Pending, as Long as They Haven’t Been Verified in Default Branch

[timvahlbrock]

Background

The purpose of pending pacts is to prevent newly contracts newly added by the consumer from breaking provider pipelines. However, with the current implementation the provider can break it's own pipelines, ones the contract has been verified on any branch. Currently the pact broker treats all contracts as pending, that have not yet been verified on a branch before the first contract publication on the current branch. This can lead to problems if the contracts have been verified on a feature branch, but not yet been merged. Example flow where this occurs:

1. Branch feat/support-new-contract is branched off from main.
2. feat/support-new-contract publishes a verification of the new contract, but is not yet merged (maybe because other tests fail, it still needs refactoring, maybe the pipeline just takes some time).
3. Branch fix/that-bug is branched off from main and runs a contract validation run. The broker detects, that 'fix/that-bug' was created after 'feat/support-new-contract' has published a successful verification of the new contract. The new contract is therefore not pending for 'fix/that-bug', but the branch also does not contain the implementation to fulfill it.
4. fix/that-bug is now blocked from merging, as long as feat/support-new-contracts isn't merged.

Disabling verification publication on feature branches doesn't help, as that breaks can-i-merge.

Proposed Change

• Treat pacts as pending, as long as the current branch was created before the contract was verified on the default branch.
• Proposed by @mefellows : Introduce a parameter to switch between old and new behavior. (I don't quite get yet, in which cases the switch would break something apart from user expectations. Maybe just publishing this as a major release is sufficient?)

This behavior would ensure, that the implementation for a new contract is available on the default branch before it is released from it's pending state. It would still allow branches from breaking pending contracts by branching off before successful verification and breaking the implementation afterwards (as was possible before), but this is caught by running contract tests on the default branch, which is required anyway. In many cases, this branch would ease the branching flow, as branches don't have to verify contracts for which they don't have access to the implementation to yet. The new implementation matches the behavior of 'can-i-merge' and therefore probably what users would expect.

Checks if the specified pacticipant version is compatible with the configured main branch of each of the pacticipants with which it is integrated.

Required work

• adapt the 'contract is pending for branch' implementation by:
  • fetching the default branch for the provider
  • check if the contract was verified on default branch, before the current branch was created (can be adapted from the current 'check if the contract was verified on any branch, before the current branch was created')
• add a parameter to enable/disable the new behavior; alternatively: create a major release without adding a switch

[timvahlbrock]

See https://www.linen.dev/s/pact-foundation/t/32725393/hey-there-everyone-i-have-a-question-on-the-flow-of-working-#44c39a32-166a-4984-9a27-f232ebc1e448 for previous discussion on slack.