Hi, I am having a conceptional question. I am trying to setup a contract between two services. A (consumer) and B(provider). To secure the communication a header is injected by a running side-container, so A actually does not know about this security header. Service B however needs this header to verify the user etc, and it is always checked before handling the requests. Where would I place setting up this header? As part of the consumer-contract? Even though the application A does not really know about it or on the provider side? At the moment I would implement a state "user exists" or "user is authenticated" in the consumer pact and try to setup this header somehow in the provider. Is this the way to go?

Does anyone know if there is a way using the V3 pact_verifier_cli to wait or retry on the state change endpoints until the provider service is done starting up? I have tried setting an explicit

--request-timeout

value, but it's still failing, so I think the way my server must work is that while it's still setting up, it's returning 500s instead of hanging

Hello everyone! I have a service that is a consumer and a provider for a least two of others of my services. I was able to make deployment on my develop environment while writing the contracts, but now that everything is working on that environment, I’m not able to deploy to my production environment since can-i-deploy would not let me, 😞 computer say no. Am I doing something very wrong? I search everywhere to find a answer to this question but didn’t got luck :(

Hi everyone, I am setting up this repository https://github.com/pactflow/example-consumer locally on my machine. I have created the PACT_BROKER_TOKEN and PACT_BROKER_BASE_URL, DOCKER, and MAKE but while running the command make fake_ci this error is showing up. Can anyone help me with this issue? 'CI' is not recognized as an internal or external command, operable program or batch file. make: * [fake_ci] Error 1

Hello, have anyone tried passing the port number for the mock server as a command line argument when running consumer tests? Tried it but failing, may be I am missing something. Any thoughts? Thanks.

@PactTestFor(providerName = "test-provider", port = "${pact.server.port}")

Hi @Matt (pactflow.io / pact-js / pact-go)@Matt (pactflow.io / pact-js / pact-go)@Matt (pactflow.io / pact-js / pact-go)@Matt (pactflow.io / pact-js / pact-go)@Matt (pactflow.io / pact-js / pact-go) and team, Ive asked this via twitter but is it viable to use contract testing if our app has heaps of integration with third-party services like zendesk, salesforce, etc. If yes, whats the best way to do it? For context, we don’t have automated integration and api tests yet.

Hello all I am having trouble understanding the benefits of handling provider asynchronous tests as unit tests instead of treating them as component level tests like the the synchronous provider tests. Let me elaborate: For the provider sync tests I am currently spinning up a docker container with the provider service and I set the provider state by writing records to a database and by simulating HTTP interactions and Kafka interactions with other downstream services. For provider async tests I can just as easily set the state by writing records to the database and simulate downstream interactions with the other services. And when it comes to verifying the message all I need to do is pull the message from the topic (I am using Kafka) and pass it on to Pact. I already have tooling in place to spin up the provider as a docker container for the synchronous tests so it is straight forward to use it for the asynchronous tests — and in my case the same provider has both asynchronous and synchronous interactions sometimes with the same consumer.

Hey there! I having a question regarding the interesting new contract testing called Bi-directional contract testing. In the given examples the provider verifies the api spec using e.g. rest assured or postman. Is it right that when the provider autogenerates the api spec from code than the provider can just publish the api spec to pactflow without any further„SELF-VERIFICATION TEST RESULT”?

Hey! Can anyone tell me if there is a way using the pact-broker CLI to retrieve information about providers and consumers given a pacticipant?

Another question: I'm using the v3 pact_verifier_cli (the one written in Rust) and it wants me to specify a consumer version selector, but I'm trying to get this to work with my

contract_requiring_verification_published

webhook, which will trigger on our feature branch build (so before it has been merged/tagged or deployed to any environment) so I just want to point at a specific consumer version when I run the verification. Is there a way to do that with the consumer version selector? Or is there some other way I'm not seeing?

So, some more info, I tried following the instructions in the description for the

pact-broker create-or-update-webhook

command, where it suggested I write a curl command and then change it from

curl

to

pact-broker create-or-update-webhook

and I did, this worked to kick off my jenkins job:

curl \
    "http://$JENKINS_BASE_URL/job/Pact%20Verify%20Provider/buildWithParameters" \
    -X POST \
    -u "$USERNAME:$PASSWORD" \
    -d project=\${pactbroker.providerName} \
    -d version=\${pactbroker.providerVersionNumber} \
    -d pactfile_url=\${pactbroker.pactUrl}

but when I change it to this:

pact-broker create-or-update-webhook \
    "http://$JENKINS_BASE_URL/job/Pact%20Verify%20Provider/buildWithParameters" \
    -X POST \
    -u "$USERNAME:$PASSWORD" \
    -d project=\${pactbroker.providerName} \
    -d version=\${pactbroker.providerVersionNumber} \
    -d pactfile_url=\${pactbroker.pactUrl} \
    --contract-requiring-verification-published \
    --broker-base-url "$PACT_BROKER_URL" \
    --description 'Automatically trigger pact verification on contract change.' \
    --uuid "$PROVIDER_VERIFICATION_WEBHOOK_UUID"

I get the exact same error:

ERROR: "pact-broker create_or_update_webhook" was called with arguments ["<http://jenkins-base-url/job/Pact%20Verify%20Provider/buildWithParameters>", "version=${pactbroker.providerVersionNumber}", "pactfile_url=${pactbroker.pactUrl}"]
Usage: "pact-broker create-or-update-webhook URL --uuid=UUID -X, --request=METHOD -b, --broker-base-url=BROKER_BASE_URL"

Very perplexing 😕

Not sure if this is Rust specific, but curious if someone else has seen the following warning when using the `pact_verifier_cli`:

[WARN] Received a ServerHelloDone handshake message while expecting [CertificateRequest]

I'm currently switching from using the Ruby CLI verifier to the Rust one in our CI pipelines by using the pact-ref-verifier Docker image. However, something currently triggers that warning to appear at the start of each verification. From my understanding it's caused by this bug introduced in 0.20.3 of Rustls, which was fixed in 0.20.5. However, the latest Docker image for pact_verifier_cli is of 0.9.10 which is still using 0.20.4 (Cargo.lock from time of release), while it seems that the master branch of the repo is using 0.20.6 of Rustls. Curious if anyone else has noticed the same thing since I didn't find anything in the workspace via searching messages. I noticed also that the Cargo.toml for the verifier was already bumped to 0.9.11 in this commit during April, but apparently no release itself was made or is it still being tested (this 0.9.11 release is still using the 0.20.4 version of rustls, so it probably won't fix this issue even if released).

Hello, hoping someone can help me with

record-deployment

and

record-release

please... When I

record-deployment

into an environment, should the

--version

be the same git commit sha for each environment I deploy to? Reason I ask is because I had a command like this

docker run pactfoundation/pact-cli:latest pact-broker record-release --pacticipant DojoPayConsumerApp \
--version $BITRISE_GIT_COMMIT \
--environment production \
--broker-base-url $PACT_BROKER_BASE_URL \
--broker-username $PACT_BROKER_BASIC_AUTH_USERNAME \
--broker-password $PACT_BROKER_BASIC_AUTH_PASSWORD

in CI for deployments and releases, where the

$BITRISE_GIT_COMMIT

version would be different for each deployment. On the

record-release

I was getting failures as it could not find the version it was looking up, would love some clarification on this please, thanks 🙂

How mature is the protobuf support? I can't seem to find much documentation on it - but the top results searching docs.pact.io are in changelogs, so maybe the functionality is there?

Hi Team, Our team at tripadvisor landed into unique issue: 1. Feature branch published pact(not new, existing pacts) 2. It triggered webhook and ran provider verification build. 3. Due to some intermittent issue(that I am checking), build failed. 4. Verification result was copied to all other consumer feature branches and canIDeploy check for all consumer feature branches started failing. 5. There was panic situation all around as all builds are failing and nobody changed pact. How it was resolved: I published new feature branch which triggered webhook and got consumer test verified. What i want to ask is : 1. What should be best way to resolve such situation? 2. When is webhook triggered, since its not new pact 3. Was the above behaviour expected or Does pact pipeline setup needs improvement?

Hey, i have an android and an iOS consumer that have the same provider and use the same Endpoint with literally no differences in response or request. The Provider Test would be identical besides the consumer annotation change. Is there a way where i can avoid that much code duplication and can have multiple consumers in 1 Test?

This message was deleted.

We have a consumer that added new contracts with consulting its provider, and that broke their pipeline. I know that communication is paramount with Pact and you encourage CDCT, but how do you tackle the case where the provider is already verifying contracts from other consumers? Does the provider need to handle all the states declared by its consumers? Is there a way to tell the consumer is experimenting?

Yes, Pending pacts (and also branches / tags)

I'd highly recommend reading the co/cd setup guide (howtolearn)

Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops

Happy Friday Everyone ralph wave Pact Foundation's Slack Emoji Game is officially on fire 8 bit courtesy of your Devo avocato with 9️⃣ 0️⃣ 0️⃣ 󠀥󠀥% moar a. it contains language specific rust / ☕ / nodejs / gopher b. it's a silly thing, but i. what randoms can you find? think bread ii. what's your favourite emoji? bobbytables iii. can we break S on a friday 2361 by having the most reacted 🧵 to ever? elmo shrug

Anyone got an example of using Pact with Typescript/Javascript aws SAM lambda SQS consumer?

I wasn't able yet to replicate this issue to actually report it with repro steps, but just for my sanity I'd already like to confirm that something like this probably shouldn't happen (first image). The verification result is marked as failed even though all the interactions (just one here) have succeeded, which seems quite odd to me. However, in the same run where that verification result was published, there was one other unrelated contract that did fail (on purpose). I'm guessing the failure from this contract propagated somehow to this other contract, but I'm not yet sure how since I was unable to reproduce this with some pseudo-pacticipants. A follow-up question here actually is that when you run the

pact_verifier_cli

(Rust) using

--url

, should it also select additional contracts using the default consumer version selection rules? In the second picture the first contract was the one passed with

--url

but I didn't expect the verifications to run with what I'm guessing is the rule

latest: true

(or whatever is the default?) in addition to it.

Hello. Is pact a good option for generating Data contracts for a yet-to-be-developed API? For context, the contract will be used both by the consumers to develop the pipeline for using the API and by the provider to have clear understanding of the work at hand.

Hi Guys, I need some general guidance to implement pact test in my project, i have a bunch of micro services written using spring boot in a product, currently there are unit tests and a lot of E2E tests responsible for testing all functionality, I am trying to use pact and possibly reduce the amount of E2E tests after that. I am confused over the scope of provider side verification tests, whether I should just mock everything beyond controller layer and send a mock response back to verify consumer pact (this approach wouldn't help me in reducing E2E tests) Or run the provider service and mock the outgoing calls and database calls so that all the provider side code gets tested as part of pact verification process (This approach has a bunch of challenges to mock all outgoing interaction points).

Hello Everyone, I'm trying to implement Pact for my lambda and my use case is as follows: I have a lambda with an SQS setup so I have one Consumer which is my lambda and I have multiple Providers (Producers) who can put data into the SQS and then to my consumer (lambda). When I try to implement this scenario I can't find a way to have a setup with one Consumer and multiple providers. Is this scenario possible to implement in Pact?

Hello 👋 Sorry if this has already been asked. I've just got a question around verifying contracts by provider that were published by branches on the consumer so get tagged with the branch name. We have found that we're having to update our provider verification code (consumerVersionTags) each time to reference the branch where the contract that was published from. I've read this page in the pact documentation and it suggests using the using the git branch name in ConsumerVersionSelectors and ensure the git branch for both the provider and the consumer are the same when the contract gets published and verified. We have tried this and it appears to work but means we'd need to remember to do this every time going forward. This document also mentions dynamically determining the tags of the feature branch which sounds like a much better option. Has anyone done this and got some examples or other suggestions?

Hello, quick question about monolith contract testing pipeline strategies: so we have monolith app (provider) with multiple consumers, what is the best strategy for blocking release(we do continues delivery) from provider? monolith(provider) got lots of responsibilities and all of subsystems are dependent on monolith, so when 1 consumer contract fail, should we block entire monolith release? until fix the contract? I know it is sounds same as monolith / micro services release issues, but I am looking for some similar real example for specifically contract testing, thanks

Hello, I am a bit confused by this apparent issue that i am encountering. Tbh I am not sure if it is an actual issue or if I am not doing things correctly. Anyway here is what is happening: I have a consumer that interacts with a provider using both HTTP and Kafka. I have two consumer tests for each, each creating its own pact file. I am publishing the Pact files to pactflow.io using the Pact cli tool (

pact-broker publish

), but when I go to the pactflow.io UI I can only see the HTTP interaction. However when I retrieve the latest pact for the provider I get a JSON file that contains both interactions and messages -- I used curl to retrieve the JSON. I also built a provider test but only for the HTTP interaction (using

HTTPVerifier

), what I am also seeing is that when I run the provider test it is attempting to verify the Kafka message. Has anyone experienced a similar situation?