https://pact.io logo
Join Slack
Powered by
# general
  • s
    Hi. This might not be pact specific but I wanted to ask in case anyone has experienced this before. My team and I added consumer driven contract testing with Pact as a pilot in two repos our team used to own approx 2 years ago. One repository, provider, is open-source. Whenever a new PR is created on provider, we run pact provider verification to ensure everything works. We have the pact access token in Github secret and that secret is used to connect to Pactflow to get contract and push verification results. Recently, the verification started to fail on some PRs while it passed on others. Upon closer inspection, it was observed that the CI was always failing when creating PR from fork. It turns out Github does not pass secrets for such PRs due to security reason (https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow). There is an option of pull_request_target (https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target) but it is recommended to not use it if one plans to checkout the code from HEAD. To summarize: We store the pact access token in Github secret and pass that to Github action. This works fine for PRs created directly on repository but not when created from fork as access token is not accessible in that GA run. Has anyone faced this particular challenge before? What was the solution you opted for?
    j
    • 2
    • 2
  • b
    Hi folks 😄, Do you have a strategy that make Pact Contract Testing for a provider easy to maintain when a provider has multiple consumers? For a consumer, pact is as easy as yet another mock server. However, for a provider that has multiple different consumers. I find it difficult to write a test that can handle different variation of pact files from different consumers, because a provider has to actually start their test server and mock behavior under the hood to make it work each pact file. For example, A provider have a GET /products/:id endpoint Consumer A's Pact file specify that GET /products/420 will returns 404 and GET /products/69 will returns a product. Now the provider implement a mock that perform such behavior. Consumer B's Pact send their pact files with GET /products/420 will return a product for the same endpoint. Now a maintainer of the provider has to read this new pact file manually to understand why it fail and update their mocked behavior to match these behaviors or reach back to the provider to have them change the product ID, because the product ID is conflicting with another consumer. Thank you 🙏
    j
    s
    +2
    • 5
    • 16
  • t
    Hello everyone, has anyone experience with using the Terraform Provider for Pact with the Pulumi Terraform Bridge? Setup seems to work fine, but as soon as I configure anything else than the Provider I get the error message "error: rpc error: code = Unknown desc = "host": required field is not set", eventhough I'm absolutely sure that the provider has the host argument set correctly.
    • 1
    • 1
  • l
    Hello everyone. Just want to know is there any resources for implementing contract testing with pact between third party services. Is it even recommended to do this ?
    h
    • 2
    • 1
  • y
  • s
    Is there a way to test out consumer version selectors using pact-cli, without running a full-on provider test? If not, can this be considered a feature request? I'd love to contribute, but pact cli is in ruby, and I don't really know enough about it (I've contributed something very minimal in the past and needed help still lol)
    m
    • 2
    • 6
  • a
    👋 Hi everyone! Issue with 
    can-i-deploy
    Failing Despite Successful Verification     Context: I am trying to deploy 
    fastag-api
    version 
    bb7321f7d645718139ea990fd6f9298a1f6272ba
    to the 
    dev-tpi
    environment. The contract tests between 
    fastag-api
    and 
    customer-api
    have been successfully verified. What I Observed: 1. Explicit version check works fine: 2. When I run: 1. pact-broker can-i-deploy \ 2. --pacticipant fastag-api --version bb7321f7d645718139ea990fd6f9298a1f6272ba \ 3. --pacticipant customer-api --version 35cfe47bdfaf1030a5e772324a042a439f018928 \ 4. --broker-base-url 5. https://pact-broker.devtools-opt.****.com 6. ✅ I get "Computer says yes \o/", confirming that this specific pair is verified. 7. Reverse check also works fine: 1. pact-broker can-i-deploy \ 2. --pacticipant customer-api --version bb7321f7d645718139ea990fd6f9298a1f6272ba \ 3. --pacticipant fastag-api --version 35cfe47bdfaf1030a5e772324a042a439f018928 \ 4. --broker-base-url 5. https://pact-broker.devtools-opt.****.com 6. ✅ Again, "Computer says yes \o/", showing the verification is valid both ways. 7. But deployment to 
    dev-tpi
    fails:     1. pact-broker can-i-deploy \ 2. --pacticipant fastag-api --version bb7321f7d645718139ea990fd6f9298a1f6272ba \ 3. --to dev-tpi \ 4. --broker-base-url 5. https://pact-broker.devtools-opt.**.com 6. ❌ "Computer says no ¯_(ツ)_/¯", with the message: FYI: 35cfe47bdfaf1030a5e772324a042a439f018928 this version of customer-api is already deployed in dev-tpi environment and also it is tagged/mapped with this environment name 1. There is no verified pact between the latest version of customer-api with tag dev-tpi (35cfe47bdfaf1030a5e772324a042a439f018928) and version bb7321f7d645718139ea990fd6f9298a1f6272ba of fastag-api. Q*uestion:* • Since the verification between 
    fastag-api
    and 
    customer-api
    is already successful, why does 
    can-i-deploy
    fail when using 
    --to dev-tpi
    ? • Does the issue relate to tagging? ◦ The error suggests 
    customer-api
    is expected to have a 
    dev-tpi
    tag, but I can confirm that version 
    35cfe47bdfaf1030a5e772324a042a439f018928
    is the one we verified against. ◦ Should I explicitly tag it as 
    dev-tpi
    using 
    create-version-tag
    ? • Is there a way to check how 
    dev-tpi
    is being used in the Pact Broker for 
    customer-api
    ? Would appreciate any insights on what might be causing this discrepancy. not able to attach the output screen-shot because of company policy :)
    m
    • 2
    • 15
  • s
    Hello! 👋 I have a question about Provider Verification and CI/CD workflow. Context/Setup: • We have an integration between Consumer and Provider. • When Consumer changes the contract, Pact Broker triggers Provider Verification Job • Provider Verification Job pulls master, runs the tests with new pact, reports back the results • In the meantime, Consumer job polls the results with can-i-deploy with staging and prod environments Situation: • Consumer adds a field to "given" block, aka the Provider State - This changes the Contract • Consumer CI runs, pact sees the change, triggers Provider Verification Job • Provider pulls master, runs the tests, and they succeed, because the new given field is not yet extracted/used Current outcome: • Provider Verification results are sent to broker • Consumer CI/CD polls the results with can-i-deploy, but sees that only prod/master is verified, but staging has no verified pact • Consumer CI/CD is red I followed the Pact Nirvana CI/CD setup where it suggested to make provider verification check with master/main branch. I do not remember there being an exact reasoning for this. We're now thinking, should it also check for other environments? Why, and why not? Am I missing something here?
    m
    • 2
    • 6
  • p
    Hey there, what if the consumer publishes a non valid contract and therefor breaks provider deployment protected by can-i-deploy? Whats the suggested mitigation?
    m
    • 2
    • 1
  • r
    Hi folks, my colleagues (a couple of them) at Verily Life Sciences would like to join this Slack workspace (we’ve made a couple of contributions to the Pact protobuf library). Would it be possible to add verily.com as an allowed sign-in email to this space? We look forward to further contributions to Pact!
    m
    • 2
    • 3
  • a
    Hi All I am using PACT with Kotlin and Spring Boot and have multiple consumers and providers. The contracts I publish are mapped to specific environments using tags post-deployment. I have the following doubts regarding how PACT verification works across different versions: a. If there is a change in a PACT contract, will it automatically be verified against all existing versions of the provider? b. Similarly, if there is a change in the provider, will PACT verify it against all live consumer versions in any environment? c. Given that I am tagging contracts based on environments post-deployment, how does PACT handle versioning and verification in such scenarios? I want to ensure that backward compatibility is maintained across versions. What is the best approach to managing contract verification when using environment-based tagging? What i feel is if there is any change in provider it will run the provider test against all the consumer versions that are tagged/mapped with different tags/environment. I need some clarification
    m
    s
    • 3
    • 9
  • g
    Hi All, I have generated the openapi-generator-cli author default mustache templates, I need to implement pact in mustache templates and generate the client, is there any direct way convert and add pact in mustache templates ? 
    npx openapi-generator-cli author template -g go -o templates-go
    npx openapi-generator-cli generate \
    -i /path/to/openapi-spec.yaml \
    -g go \
    -t /path/to/templates-go \
    -o /path/to/generated-go-client
    y
    • 2
    • 4
  • g
    Hello. I've recently found this link. I'm interested in generating skeleton pact test code from swagger documents, where can I get more info on that? thanks
    b
    g
    • 3
    • 3
  • v
    I am encountering an issue while running my provider tests in a Gradle Kotlin Spring Boot project. I have a contract with 10 test cases, and my provider tests are split across two files—one file covers 2 states, while the other handles 8 states. However, when I run my provider tests, the contract checks for all 10 states in each file instead of only the relevant ones. As a result, I get 10 passing tests but also 10 failing tests because each file is validating all the states, leading to incorrect failures. things i have already tried: 1. moving SpringBootTest to base call 2. https://stackoverflow.com/a/79264442 please help ASAP Slack Conversation
  • f
    Hello everyone, i was tasked after defining contract testing with messaging pacts in our company to try adding contract testing to on of our C++ projects. But if i look at the repo it seems that there is no support? anymore. Is the current state even able to do provider tests especially with messaging pacts? And what would be a good alternative to go at this problem? Thank you in advance for your time :)
    m
    y
    • 3
    • 9
  • p
    Hi there, is there support for standard platforms like 1. Mendix 2. Salesforce running as provider?
    m
    • 2
    • 2
  • v
    Provider verification test passes and deployed till uat but can-i-deploy of consumer is failing. I am not able to understand why it is failing
    y
    • 2
    • 1
  • l
    Thank you to @Yousaf Nabi (pactflow.io), @Tien Vo and the PACT team for sending me a Tee for the participation with Tien on PHP I was helping because I like to explore cool tech and it seemed there was a gap in PACT PHP, which in 2022 I was using for work. It's amazing to see all the improvements made and the group going from success to success!
    m
    g
    y
    • 4
    • 5
  • a
    Hi I am getting this in pact broker and can i deploy for this version is failing what is the reason here i m not able to get it. Here i see it is saying pact was pre verified but status colour is green that is making it more confusing
    y
    • 2
    • 1
  • d
    👋 I'm trying to enable 
    can-i-deploy
    to environment 
    staging
    from the provider, so far i have done the following • Publish consumer contracts • Added provider verification for the above consumer • Added the webhook verification when consumer changed something Here is the error from provider
    Copy code
    pact-broker can-i-deploy \                                               
  --pacticipant=participant-video-service \
  --version=33719d37665b7f096c6e88036cd5194faab6e4f8 \
  --to-environment=staging \
  --broker-base-url="<https://usertesting.pactflow.io>" \
  --broker-token="<>" \
  --output=json
{
  "summary": {
    "deployable": null,
    "reason": "There is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and the version of analytics-video-data-service currently in staging (4474f9fd7db43b47b1d9bb390e32a4f29faf7b55)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of data-platform currently in staging (no version is currently recorded as deployed/released in this environment)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of participant-test-plan-service currently in staging (no version is currently recorded as deployed/released in this environment)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of participant-video-manager-MESSAGE currently in staging (no version is currently recorded as deployed/released in this environment)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of participant-video-manager-REST currently in staging (no version is currently recorded as deployed/released in this environment)",
    "success": 1,
    "failed": 0,
    "unknown": 5
  },
  "notices": [
    {
      "type": "error",
      "text": "There is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and the version of analytics-video-data-service currently in staging (4474f9fd7db43b47b1d9bb390e32a4f29faf7b55)"
    },
    y
    m
    • 3
    • 53
  • k
    Heya, I hope I have the right channel for this. I am trying to introduce (consumer driven) contract testing in our company, and picked a frontend and backend service as a pilot, but I seem to run into a chicken-egg problem, because they are already sharing an openapi spec file between them. And the frontend uses this file to generate the backend calling code. For the sake of example and to test my knowledge, lets forget the existance of the openapi file for a sec, and look at a scenario where the frontend is building a new feature that requires a new endpoint of the backend. If I understand the concept of consumer driven correctly, then it should look something like: 1: Frontend creates a new feature, and add some point during development reaches the point where they require the new backend call to get some data. 2: Frontend creates a new consumer test, in which they stub the backend in a way that they would like to receive the data. 3: When the test passes, a new contract is created containing the new endpoint, and data they expect to receive (the interaction) 4: Frontend pushes the contract to the broker 5: Backend pulls the contract from the broker, provider test fails, and implements the endpoint according to the expected result. 6: Once the provider test passes, both consumer and provider proceed to merging and deploying their changes. First of all, is my understanding so far correct? Now back to the usage of an openapi spec. Where I struggle in this specific case, is that the consumer uses the openapi spec to generate their backend calling code. If it is up to the consumer to write a consumer test first, how can they do that when they depend on the spec file to generate the calling code? The frontend cant write a test without the openapi file, but the backend cant provide the new openapi file without a new contract first. How do you transition from a 'provider first' to a 'consumer first' way of working when they were already sharing openapi file? The only thing I can think of is that the frontend first manually writes some temporary backend calling code, and uses that in the test. New contract is generated and pushed, backend pulls, implements, and sends the new openapi spec back to the frontend, where they then generate the new backend code, and replaces the temporary code with the generated one. But that seems very cumbersome and a very tough sell. When theyre already using openapi, perhaps the most logical answer would be to use bidirectional testing? But we are specifically looking into consumer driven, because we want to do value specific asserts. And bidirectional only does structural asserts right?
    y
    • 2
    • 4
  • j
    probably a silly question but my team is really struggle with which jobs we need to be running in which context for a provider. 1. we have a webhook trigger job to verify our consumers. this seems to make sense 2. we should have can-i-deploy running in our main pipeline before deployment to make sure that we have an acceptable pact agreement. makes sense 3. branch pipelines with changes going into the main branch (MR/PR) this is where we are stuck a. we had roughly the same trigger pipeline running verifyPacts but this was aparently cause consumers to verify against the wrong version and fail (the branch instead of mainline) b. it seems like we should be able to run can-i-merge but this would require publishing the verification which was causing us issues. would be great to get some clarity on this so we can figure out what exactly it is that we need to fix. i feel i have scoured the documentation quite a bit and everything seems to be in the context of the consumer thinking2
  • f
    I’m a bit confused about the way consumer tests work when it comes to multiple interactions. For context, I’m working on a C++ wrapper that uses a pact plugin for a custom transport, in case that matters. When I create a pact and define the interactions in each test case, each time my 
    runTest
    method is called which calls 
    pactffi_create_mock_server_for_transport
    I see the 
    StartMockServer
    method being called on the plugin with the JSON pact only containing the interactions defined up to that point. Now the part I don’t understand is what the mock server is supposed to do here, is it supposed to listen for all of the defined requests? If so, how are you supposed to distinguish between interactions with the same request but with different provider states? Or is the idea that the mock server only responds to the last defined interaction?
    r
    • 2
    • 27
  • f
    We’re working on using matchers using the 
    pactffi_matches_json_value
    function, and are seeing some unexpected behavior for some more advanced rules where the check passes even though it shouldn’t… For example, with an 
    arrayContains
    matching rule, no error is returned even though an array with one element that doesn’t satisfy the matching rules is passed to it. Here’s the line in the pactffi log for the check:
    Copy code
    2025-03-31T15:16:12.632536Z DEBUG ThreadId(01) pact_matching::json: JSON -> JSON: Comparing '[{"baz":42,"foo":"bar"}]' to '["bla"]' using ArrayContains([(0, MatchingRuleCategory { name: BODY, rules: {DocPath { path_tokens: [Root, Field("baz")], expr: "$.baz" }: RuleList { rules: [Type], rule_logic: And, cascaded: false }} }, {})]) -> Ok(())
    We’re using pactffi release 0.4.26 btw, am I missing something here?
    m
    • 2
    • 3
  • g
    Hey team, Im facing this error once I try to log in: 
    Error.
     
    412: We only support one authentication type at this time. Please try the type you used to sign up with.
    m
    • 2
    • 6
  • o
    Hi I would like to know if it is possible to configure Pactflow to automatically assign users to teams upon authentication via SSO, for example, using Azure Active Directory (Azure AD). The goal is for Pactflow to map the groups a user belongs to in the Active Directory (AD) during the login process, and based on that information, automatically assign them to one or more specific teams within the platform. This would allow the appropriate permissions and roles to be applied from the first login, without requiring manual assignments. Is it possible to enable this functionality to map SSO groups to Pactflow teams?
  • j
    Hi team, I’m looking for some advice on our current Provider's CI/CD setup with Pact Broker. We have two separate branches: 
    staging
    and 
    production
    , which may contain different code as features are tested in staging before being rolled out to production. 1. Would it make sense to maintain separate sets of Pact stages for each branch? 2. I've observed that when a webhook is triggered, the verification always runs against the main branch (staging), regardless of which branch initiated the process. This could potentially cause issues when the branches diverge. Any suggestions on how we can improve this setup or handle branch-specific verification more effectively? Thanks! Slack Conversation
  • a
    Hi. I have a json structure like this:
    Copy code
    {
  "data": [
    {
      "id": "123456789"
    },
    {
      "id": "111111111",
      "optional_stuff": {
        "data_map": {
          "blah_1": true,
          "blah_2": 123456
        }
      }
    }
  ]
}
    So my question is how to write the pact contract such that 
    "id"
    is mandatory but 
    "optional_stuff"
    is optional? At the moment I have to only specify the 
    "id"
    part as it's unclear if pact supports optional data.
    y
    b
    • 3
    • 4
  • t
    Hi, I think I have a common question but I couldn't find a guide for it so I decide to ask here. What should we do to write a consumer test for a retrieve endpoint that requires resource ID to be generated automatically on the provider side?
    b
    • 2
    • 3
  • j
    Hi, I'm currently using Pact Python v3, and I'm trying to implement consumer version selectors with a version for a specific consumer. However, I couldn't find any documentation or guides specifically for version 3. Is it possible to add a consumer version selector in this version of Pact Python? Below is the code I’m currently working with:
    Copy code
    verifier = Verifier().set_info(name=PROVIDER_NAME, url=PROVIDER_URL)
verifier.broker_source(url=URL(settings.pact_flow_url), token=settings.pact_broker_token)
verifier.set_state(url=PROVIDER_URL / "_pact" / "callback", teardown=True)
verifier.filter_consumers(consumer_name)
verifier.set_publish_options(version=str(version))
verifier.verify()
    Thanks for your help!
    y
    • 2
    • 2