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
Webhooks: trigger GitHub APIs using App Installation Tokens instead of PATs
To be able to use the GitHub App mechanism to trigger API endpoints for the webhooks you need to be enable to store the GitHub App's certificate in the pactflow broker. Besides the certificate also the GitHub App's identifier / installation id needs to be stored. Once the certificate is available, the following steps need to be consider for authentication: 1. Generate and sign a JWT token using the app's private key: https://docs.github.com/en/developers/apps/building-github-apps/authenticating-with-github-apps#authenticating-as-a-github-app This token is valid for maximum 10 minutes. 2. Use the JWT token from step 1 and create an installation token: https://docs.github.com/en/developers/apps/building-github-apps/authenticating-with-github-apps#authenticating-as-an-installation $ curl -i -X POST -H "Authorization: Bearer YOUR_JWT" -H "Accept: application/vnd.github+json" https://api.github.com/app/installations/:installation_id/access_tokens This Bearer Token is valid for 60 minutes 3. Call the webhook/GitHub API with the Bearer Token from step 2. Thanks
Support "maybe" in the pact broker
Swagger validation (and other spec-based validation) don't give the same confidence as a direct pact verification. At the moment, these would be treated the same. It would be great to be able to model different levels of deployment confidence in the broker. One way to do this would be with a "maybe" status for can-i-deploy. Other ways might be several levels of deployment confidence, or different categories.
Make http://canny.pact.io/ redirect here
That way I can type it in the URL and I don't have to remember which way round they are
Add can-i-merge functionality
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.
Support Apache Avro
Apache Avro is a common data interchange format. Supporting it enables use cases for data pipelines and event driven architectures with tools like Kafka.
Pact Consumer Dart
It would be awesome to have a Pact Dart Consumer. My main use case would be to use it on a flutter application that is consumer of multiple pact enabled providers.
Support environment/releases on describe-version
Currently, describe-version support only tags. It'd good to have the same behaviour for environment and releases. Something like describe-version -a PACTICIPANT --environment SOME_ENVIRONMENT returns a table of pacticipant versions marked as deployed and/or released
Github Action which installs Pact CLI
If one wants to run Pact tests for whatever language, the Pact CLI tools are commonly required. Please provide a Github Action which installs the CLI tools in a Github Actions workflow. Make the version of the tools a configurable property.
Once a PR is merged into main/master or closed, I would like the ability to delete all pacts associated with that branch because that particular pact should either exist in production or will become the baseline pact for future development. Currently this is especially cumbersome because of things like renovatebot for github actions automatically creating a lot of PRs in our workflow, so it quickly is cluttering up Pactflow and makes it hard to see the contract (on main) that we care about.