What's the best way to roll out a new pacticipant? I've started building our automation around our pact broker, and I've reached the point where our pipeline will fail pull-request builds if

can-i-deploy

for the given service to deploy to

master

fails... But now I've discovered that when build a new pact provider, it fails

can-i-deploy

because it doesn't exist yet as a pacticipant, and when I add new contract tests to a service, it fails because the contract can't yet be verified, so I'm in a bit of a dependency loop. Is the only way out of this dependency loop to do a one-time suspension of my checks to get my provider merged? Am I maybe doing something wrong? (To be clear, currently my script currently checks to see if the pact provider logic has been implemented in the service and if it has, it runs verifications and then the

can-i-deplay

. It doesn't run any pact stuff if it doesn't see the pact provider logic or a pact file in the service)

Hey there, im trying to test Kafka messages with Pact. We are using Avro to send the messages, but i can't find any documentation for that. Help would be appreciated. Thank you.

👋 , i tried to search the documentation for more info about environments, but i couldnt find anything to help describe the option

--no-production

for the cli

pact-broker create-environment

, documented here. is this option purely informational when creating an environment, or is it used somewhere like provider verification?

Anyone familiar with that error "ERROR pact@9.18.1: error making http request: axios_1.default is not a function"

Hi 👋 , we are thinking of adding Pact to our tests. We have one concern about running the provider's verification. Currently, we are running our services locally in isolation by binding the application interfaces to mocks using IoC. Now, if we want to start using Pact we will have two mock systems, one for tests, and one for an isolated local run. I want to be able to configure and run the Pact mock server locally when running the application. --or-- Use the existing mocked implementations to configure the expected interactions in the tests. Is that possible? Do you have any idea on how to do that correctly? I opened a discussion in GitHub with more details: https://github.com/pact-foundation/pact-js/discussions/887 What do you think about this concern? How do you run your app locally in isolation?

Hi Folks, I joint pack to understand for implementing project just share me any guidance which is useful thanks on advance.

A quick question for the experts 1. If we already have schema and integration tests in our CI pipelines and are tested as a part of each PR to master, do I still benefit from using Pact? 2. We are following the following approach: Acceptance Criterias created by BA-> Team refines the story -> Squad teams pick up the story fort implementation(please bear that the contracts are not ready here, before our domian services needs to call the third psrty vendor’s APIs) -> Implementation completed (domain services end points created after understanding how the third party vendors apis behave)-> Swagger docs are created-> QEs create their integrations tests and schema tests and are ready to merged into the main PR-> PR is now raised against master -> all checks are made before it gets deployed to master.. Same happens at the consumer side as well.. Can somebody let me know if we would still benefit out of Pact and if yes how? Highly appreciate your thoughts on it. Thanks

Hi all, quick question, I am trying to use the can-I-deploy command, and I am getting authentication failed. Is there anything I have only installed pact-foundation/pact, is there something else I need to install to get it to work?

Hi, I just wanted to flag for a potential problem in the workshop, unless I did something wrong.I ran through the workshop https://github.com/pact-foundation/pact-workshop-jvm-spring yesterday, and I experienced errors about authentication already in ~step 5. So, "Yay - green" was not the case. But after step 10, all was ok again.

I've been using Pact (pact-js) for GraphQL contracts between client apps and Apollo GraphQL servers, by using pact-js on the client side and server verification tests that allow pact to check the GraphQL response meets contract expectations. Now I'm looking at moving to Apollo Federation, and trying to figure out whether pact could still be used in this context. In a federated architecture there is an single API Gateway sitting in front of multiple subgraphs, responsible for composing the schemas from those subgraphs into one unified supergraph that is consumed by client applications. Each subgraph is a separately versioned deployable component (as is the gateway itself), but from the client perspective the behaviour of the GraphQL server is the same as in the non-federated case. In the non-federated case, the GraphQL server is a single versioned (consumer) pacticipant in this case. In the federated case however, the gateway itself is a relatively thin component whose source version rarely changes, and each subgraph is more like a non-federated server with its own version history. When a contract between a client and the gateway is verified, this is in effect saying that N (where N is the number of subgraphs) "sub-contracts" between the client and each subgraph are verified i.e. can-i-deploy for the client depends on the versions of all the subgraphs used to service the query. As client requests will typically span multiple subgraphs, defining contracts between clients and subgraphs isn't the right approach; the contract should be between the client and the supergraph. It feels like this would be quite a technical challenge - from the client perspective there is one contract, but from the provider perspective there are multiple contracts because each provider (subgraph) has a role to play in servicing the query. There isn't a single deployable versioned component that can take the role of the provider here because the gateway itself isn't changing when the subgraphs change, unless one invents some pseudo-deployable supergraph pacticipant whose version depends in some way on the versions of all contributing subgraphs but is never really deployed, just recorded in the pact broker as such. I'd be interested in any thoughts on this; it feels quite complex to manage and use, but maybe I have missed something.

Hi all, my team and I are looking into what is the best way to split the creation of contracts between consumers and providers, let me elaborate. We have a monorepo for the consumer (front-end) and several different provider services, do we create one pact file for each controller or for each endpoint? There are countless ways to go about creating contracts between the providers and the consumer but I'd like to hear what everyone else thinks about this?

Hi everyone , My use case is that my consumer is an API service i.e. it exposes Rest API Endpoints , however the provider internally it calls is a gRPC service. Moreover its more like a passthrough service for Provider APIs So the consumer <-> provider are integrated via gRPC. I read that the gRPC support is not there yet. So does that mean there is no way to go ahead contract testing this use case with Pact ? Any help is appreciated , thanks

Hi everyone, what is pact/pactflows capabilities when it comes to slack, jira, and testRail integrations, I thought I read somewhere that they are able to provide slack messages with webhooks?

Hey. I repeatedly have people saying what they really want is to write isolated functional tests and then feel confident that the mocks they are using are correct. The way many people are solving this is by doing a record/playback approach, where they run their tests in staging on a weekly basis, record the results, and use these as their mocks. But I thought it would be great to say "use Pact to define your mocks, run your functional tests, and then use the Pact mocks to verify your provider." But in the docs you recommend not doing this for reasons I don't fully understand - something about the mocks defining a contract that is too constrictive and which breaks even when the contract has not broken. Can you explain more? I am very tempted to start using Pact as the mocks for functional tests, but not if this is just a non-starter use of Pact. Thanks!

Hey all! How do you guys go about organizing pacts in pactflow? Is there a way to group pacts per API version or per team atc?

I see the words participant and consumer being thrown around interchangeably, is there a difference between them or are they the same thing?

It looks like publishing a new contract does not trigger the

contract requiring verification published

event/webhook. Is this intended behavior?:

Events detected: contract_published, contract_content_changed (first time untagged pact published)
  No enabled webhooks found for the detected events

Hi Pact community. Looking for some advice on how to integrate Pact into runtime and/or deployment checks. We run our microservices architecture on Kubernetes using FluxCD2 to provide a GitOps deployment model.

We have pretty good coverage with Pact contract tests but these only run as part of our CI. There is no CD pipeline anymore. We simply update the declared state in git and Flux will apply the state in the K8s clusters.

I am looking for advice on how to implement the can-i-deploy checks in this model. Our infrastructure team thinks we should use helm pre-install hooks for deployment checks or readiness probes for runtime checks, but doesn't want to put our Pact Broker in the critical path.

We have multiple production environments, so we need to track each of our deployments and rollbacks in the pact broker and then run can-i-deploy prior to deployment or before becoming ready.

Currently, the proposal is to implement a version API on each of our microservices and have each service track its required dependency versions and do a runtime or deploy time check to make sure dependency versions are satisfied in the environment. But this is totally sidestepping Pact for dependency management. 😮

Anyone, I'm wondering if anyone else has implemented something for "GitOps" that might satisfy our infra team.

One thing I had to say.. Pact has awesome DOCUMENTATION. It looks like they are very particular for the users to actually use it, documentation is not one-sided, it also talks about down-sides of Pact and how we can overcome them. KUDOS to the TEAM for a fantastic DOCUMENTATION. clap all

Hey, something came up recently and I'm not sure what the correct "pacty" way to handle it is: I have a POST rest endpoint I'd like to test which takes an object and creates it in the database. One of the properties on this object must be the ID for an inner object that must exist already in the database, so in my state setup function inside my provider I'm creating the inner object. The problem is that the object is always created by the database with a random UUID, and a database constraint prevents me from creating the object with a known ID. So how do I write my contract such that the object being posted is using the ID of the inner object in its own properties if it's randomly generated? I see that I can use matchers in the POST body in the contract, but if I don't actually know the real ID of the inner object that was created during the setup, I'm going to get a 400 error when I try and post my new object because it's not matching on a valid row of the inner object in the provider's database, so the matcher doesn't actually help me in this instance. Thanks!

Hey hey 👋 . I have a question about ‘dev’ environments when pacticipants are deployed to it by N feature branches. We have a setup where each branch is deployed in to a shared ‘dev’ environment but it itself is physically separate than any other ‘instances’ of that consumer/provider already in that environment. So Provider A on

feature/123

and Provider A on

feature/234

will have different versions but they’ll represent two distinct instances. This leads me to think about using

record-release

so the other versions are not marked as undeployed (as

record-deployment

will do for you). Our upper environments all have 1 instance of each pacticipant so a normal

record-deployment

workflow will suffice. Is using

record-release

the best for this setup over

record-deployment

with the

--application-instance

to a ‘dev’ environment like this? If you know of anywhere in the docs or working examples you could share that would be amazing ❤️ .

Hello, any recommendations on using Pact for server to server communications involving files. Examples SFTP file transfers, S3 pre-signed URL file downloads, SWIFT files. I see the file handling as more of functional testing and not contract based. But we have encountered some microservices moving large amounts of JSON via files experience an occasional breaking change.

Just a quick question is pact written in ruby but been refactored to rust via the ffi?

hi! is there some way to check

can-i-deploy

against all version , having tag

live

and deployed within n months? like am i

compatible with all versions deployed to live within 3 months?

I've encountered a CI/CD design blocker that I can't seem to get around: I was planning to create a pact on every commit, use the commit sha as the consumer version, and the branch committed in, as the consumer branch. I was planning to use github statuses to report whether a commit is compatible with the API, where, once the provider publishes the test result, a webhook will be triggered to change the consumer commit status in accordance with the test result. Now this causes this issue to arise: If a branch commit produces the same pact as the previous commit, how do we get the status of the new commit to be the same as the previous one, without having the provider test every single pact that is published? 'Branch Commit' meaning a commit with the branch set as XYZ on Pactflow. We are assuming we are committing on the same branch in these scenarios. I initially thought, that you could set a webhook on pactflow to be triggered when a duplicate pact is published, but that's not an option in the webhooks. So basically I have no idea how to get around this issue.