Feature Requests

(I wanted to get this in as there have been a few conversations - more details to follow) See https://pactflow.io/blog/the-curious-case-for-the-provider-driven-contract/ for more background.

It would be great to be able to verify Pact implementations against specifications, in order to ascertain feature parity, completeness and to help aid in testing cross language issues. See https://github.com/pact-foundation/pact-compatibility-suite for initial work * JVM https://github.com/pact-foundation/pact-jvm/tree/master/compatibility-suite/pact-compatibility-suite * Rust https://github.com/pact-foundation/pact-reference/tree/master/compatibility-suite/pact-compatibility-suite

With tags deprecated, and a setup with no automatic deployment from master branches to any environments, there is no way to check in a PR merge pipeline if it is safe to merge a PR into master. Adding the equivalent of can-i-merge --pacticipant consumer --branch feat/xyz --with master of the target provider would solve this. The assumption of all providers using the same branch name could be circumvented by allowing it to check the mainBranch of providers.

A month long celebration of 10 years of Pact, designed to facilitating community events across the globe to celebrate and acknowledge the journey and look forward to the future of Pact. Overall aims of the endeavour Contributor engagement: a thriving open source community is one that provides value to contributors and users of the software, alike. This milestone is an opportunity for us to share with the world the great aspects of Pact and to attract and excite new contributors and friends to the ecosystem Awareness: contract testing is becoming well adopted across the software development landscape but there’s still a way to go – our hope with this milestone event is to further grow awareness of contract testing Celebration: and of course, we want to celebrate 10 years of Pact in a fun way! It’s so important to us that we acknowledge the founders, maintainers, contributors, and community who have put in time and energy to make Pact what it is today Register your interest here https://pact.io/pactober or feel free to comment below

Apache Avro is a common data interchange format. Supporting it enables use cases for data pipelines and event driven architectures with tools like Kafka.

This is to add the support on adding a 'cert' and a 'key', regarding a self-hosted Broker that requires a 'cert' and a 'key'. This will make the availability to call the 'Pact::VerificationTask' adding the 'cert' and 'key' to interact with the Self-Hosted Broker. As an example: --cert /path/to/client/cert.pem --key /path/to/client/key.pem

Currently, you can only have one type of pact for each consumer/provider pair (eg. http or message). This feature would add support for publishing pacts with different protocols, and incorporating them into the can-i-deploy calculations.

gRPC is a common microservice framework. Commonly used with Protobufs as the encoding, and HTTP/2 as the transport, it is a highly efficient and type safe architecture. It is often said that contract testing is not required, due to forwards/backwards compatibility encoded into the schemas. Arguments for gRPC and Protobuf support in Pact See https://developers.google.com/protocol-buffers/docs/overview * > "You can add new fields to your message formats without breaking backwards-compatibility; old binaries simply ignore the new field when parsing. So if you have a communications protocol that uses protocol buffers as its data format, you can extend your protocol without having to worry about breaking existing code." * Whilst this won’t break the “contract”, it may actually not be a plausible situation. There are no guarantees that the actual RPC service will still work as expected The protocol definition itself doesn’t guarantee it can handle all situations the consumers expect to use: * Proto 3 removes “mandatory fields” - "Making every field optional provides a clearer contract to clients. They are explicitly responsible for checking that every field has been populated with something valid." * This means specification examples (ala Pact) are very important to ensuring the functionally contract behaviour * Similar issues to the challenges of "Optional" or "Any" schemas in SOAP SOA architectures Backwards guarantee doesn’t tell you _forwards_ compatibility i.e. it doesn’t help you coordinate a release OneOf semantics - see https://developers.google.com/protocol-buffers/docs/proto3#backwards-compatibility-issues The protocol buffer is separate to the HTTP endpoint serving it. See value prop from above It is absolutely possible to break a proto file by modifying numbered tags (field identifiers) or removing fields Related Resources * Buf ( https://buf.build/ ) - a useful tool for static protobuf linting, backwards compatiblity checks and introspection

Allow pact to be extended by a general purpose plugin infrastructure See https://github.com/pact-foundation/pact-specification/issues/83 for proposal