Feature Requests

Currently there is no way using the new environments approach to get/describe version within a specific environment. As a workaround I have had to use legacy tagging and create a version tag immediately after we record-deployment into an environment. I can then use this version tag when I describe version with the specific tag passed in. Seems there is a gap here between what you can do with legacy tags and the new environments approach. My reason for needing to do this is because I reached pact nirvana for one service, and now when I add new services, pact can-i-deploy fails on the new services as they are not fully setup with recording deployments/releases etc yet, so I was advised in Pact Foundation slack workspace as a temporary workaround to instead run can-i-deploy against specific pacticipants and versions until the other newly added services are ready too. For example, with a version tag I can do pact-broker describe-version -a ProviderService -l $TAG -o json | jq '.number' But there is no similar approach using environments approach instead of legacy tags.

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.

At the moment, can-i-deploy returns false if you're trying to deploy a consumer without a provider, but true if you're trying to deploy a provider without a consumer. This is appropriate behaviour if the consumer is an HTTP client, and the provider is an HTTP server. In some contract types (eg SQS messages), both sides can safely deploy without the other one there. With websockets, an HTTP client might be the producer. A common scenario for websockets is two contracts - one between the client(consumer) and the servir (producer), and the other between the server (consumer) and the client(producer). The current behaviour of the broker will make it impossible to deploy a websocket server without a client, and impossible to deploy the client without the server. All these problems could be fixed if it was possible to specify at a contract level which of the consumer / provider need to be present (or not) in order to deploy.