Add support for branches in consumer version selectors

The Pact Broker now supports branches as first class entities. You can read more about this here: https://docs.pact.io/pact_broker/branches

Description

Please add support for specifying branch related properties in the consumer version selectors that are sent to the Pact Broker when requesting pacts to verify. Please do not do any verification of the consumer version selectors on the client side - the validation rules are subject to change. Just ensure that any error response is displayed to the user.

• For implementations that wrap the pact-ruby-standalone, update to the latest standalone version
• For implementations that use the rust implementation, update to the latest rust version.
• Add a String branch property to the consumer version selector (if there is a domain model for this).
• Add a Boolean mainBranch (or main_branch for snake case languages) property consumer version selector (if there is a domain model for this).
• Add a Boolean matchingBranch (or matching_branch for snake case languages) property consumer version selector (if there is a domain model for this).
• Expose and document the branch, mainBranch (or main_branch for snake case languages) and matchingBranch (or matching_branch) properties in the user facing API.
• Pass the branch, mainBranch and matchingBranch (must be camelcase) through to the relevant implementation (ruby and/or rust)

Verifying the changes

• Publish test pacts to the test broker

export PACT_BROKER_BASE_URL="https://test.pact.dius.com.au"
export PACT_BROKER_USERNAME="dXfltyFMgNOFZAxr8io9wJ37iUpY42M"
export PACT_BROKER_PASSWORD="O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1"

docker run --rm  \
  -e PACT_BROKER_BASE_URL  \
  -e PACT_BROKER_USERNAME  \
  -e PACT_BROKER_PASSWORD  \
  pactfoundation/pact-cli:0.50.0.14 \
  publish \
  /pact/example/pacts \
  --consumer-app-version fake-git-sha-for-demo-$(date +%s) \
  --branch main

docker run --rm  \
  -e PACT_BROKER_BASE_URL  \
  -e PACT_BROKER_USERNAME  \
  -e PACT_BROKER_PASSWORD  \
  pactfoundation/pact-cli:0.50.0.14 \
  publish \
  /pact/example/pacts \
  --consumer-app-version fake-git-sha-for-demo-$(date +%s) \
  --branch feat/x

• Using your pact client library, verify { "mainBranch": true }
  • You should receive the main pact
• Using your pact client library, verify { "branch": "feat/x" }
  • You should receive the feat/x pact
• Using your pact client library, verify { "matchingBranch": true } with the provider branch set to feat/x
  • You should receive the feat/x pact

[tinexw]

Hi @RadekKoubsky , I started working on this issue but got stuck at some point and did not have time go back to it. If you want you can pick up where I left off. My current version can be found here.

Some of the open tasks:

• Finish the logic to build the selectors based on the annotation values in PactBrokerLoader#buildConsumerVersionSelectors and add tests.
• Add system poperties for new attributes
• Decide how to handle the open questions regarding backwards compatibility and the latest tag (s. my comment below) and implement it.
• Rebase with master and fix the build afterwards.
• Add providerVersionBranch property.
• Implement new properties for maven and gradle.
• (Optional) Improve the way errors from the broker are shown to the user. Right now they are only logged on DEBUG level.

[tinexw]

Yeah, in theory yes but that it’s even more “magic”. The current implementation already contains some “magic” e.g. there is the option to either give a list of latest values or a single one or to omit and this is not really documented (or at least I could not find it). I would really opt for simplifying the current implementation instead of adding more “magic”. The optimal solution in my opinion would be to just pass through all the attributes as is and have the broker do the validation.

Just in the case above you would need to add the same logic for the matchingBranch for example and there are more properties coming e.g. deployed and released.