https://pact.io logo
Join Slack
Powered by
hello - i need some assistance with pactflow. We...
# pactflow
h
hello - i need some assistance with pactflow. We're introducing a new integration and the provider main branch cannot detect any 
for-verification
pacts, however we have a pending pact to be verified on a feature branch for both the consumer and provider.
I've tried to debug myself and I can verify the HAL browser is not returning any 
for-verification
results using these steps. Env is pact-go 2.x.x and using 3.0 spec. Steps to debug: 1. pact-go provider-verification, set log level to 
DEBUG
, this gave the output:
Copy code
Sending JSON to https://[redacted].<http://pactflow.io/pacts/provider/[Redacted]Service/for-verification|pactflow.io/pacts/provider/[Redacted]Service/for-verification> using POST: {"providerVersionTags":[],"includePendingStatus":true,"includeWipPactsSince":"2022-04-15T00:00:00Z","consumerVersionSelectors":[{"mainBranch":true},{"matchingBranch":true},{"deployedOrReleased":true}],"providerVersionBranch":"main"}
2. Posted in the HAL Browser and received no results 3. Confirmed in the HAL Browser that pacts exist,
Copy code
https://[redacted].<http://pactflow.io/pacts/provider/[Redacted]Service|pactflow.io/pacts/provider/[Redacted]Service>
m
Hi Haz, could you please raise a ticket at support@pactflow.io? We’ll need the specific provider details and of course your account so we can check for you. Just in case, the logic for detecting “wip” is outlined here: https://docs.pact.io/pact_broker/advanced_topics/wip_pacts#technical-details. Worth double checking that the pact you expect to verify matches that criteria
👍🏽 1
h
This is for documentation purposes on this workflow I follow. FWIW it feels like a regression since this has been how I've introduced new consumer driven pacts in the past. 1. Define a new pact for consumer "FooService" on consumer branch 
feature/fun-123
with a new provider "BarService". a. BarService does not have any real pacts on main branch 2. Use CI to publish the pact with 
branch=feature/fun-123
3. New integration exists between FooService pact open link BarService a. The newly published pact in unverified, so I'd call this 
pending
4. BarService implements the verification on like named branch, eg 
feature/fun-123
5. Provider CI executes on feature branch a. Provider Verification Configuration i. ConsumerSelectors 1. mainBranch = true 2. matchBranch = true 3. deployedOrReleased = true ii. IncludePendingStatus = true iii. IncludeWipPactsSince = yep b. 
for-verification
api returns the new pact c. Verification is success. d. can-i-deploy is a success 6. Provider merge to main a. Repeat 5a and 5b on main branch i. 
for-verification
does not find any pacts to verify b. can-i-deploy fails due to no successful verifications on main branch At 5c, I would think the pact although first verified is still consider pending and therefore should be returned in 
for-verification
api given the provider verification configuration. Even if it's WIP at this point it is still pending or at least I thought. I think my work-around is to delete the verification on the initial provider feature branch to put the pact back in unverified. I did this with a clone existing and used the same query on a provider main branch and was able to get back a pact requiring verification.
yep - i opened a ticket 
#00544115
👍 1
Curious as to how/when pacticipant gets their main branch set. Eg, I noticed another provider recently onboarded has this set using the cli describe-pacticipant
Copy code
Main Branch: main
m
h
Interesting, so had my main branch verification found a for-verification pact and verified then this would get set.
Any insight on pactflow side would be helpful, still seems like a bug
I did not try my work around yet
m
Interesting, so had my main branch verification found a for-verification pact and verified then this would get set.
only on the provider To set it on the consumer, it’s when the contract is published (or if explicitly set)
Once the ticket hits the L3 team they’ll dive into the data for you on the PactFlow side
👍🏽 1
b
@Hazem Borham sorry it’s taken so long to get back to you on this. I’ve reproduced your scenario, and this is what the WIP explanation logs say:
Copy code
2023-03-30 11:42:44.975904 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Potential WIP pacts for provider branch main created after 2020-01-01T00:00:00+00:00 by consumer branch -- ["FooService 2 (branch feature/fun-123)"]
2023-03-30 11:42:44.976124 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Potential WIP pacts for provider branch main created after 2020-01-01T00:00:00+00:00 by consumer tag (none)
2023-03-30 11:42:44.976474 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Ignoring pacts explicitly specified in the selectors (none)
2023-03-30 11:42:44.976793 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Ignoring pacts successfully verified by this provider branch when not WIP (none)
2023-03-30 11:42:44.977383 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Ignoring pacts successfully verified by another provider branch when not WIP -- ["FooService 2 (branch feature/fun-123)"]
2023-03-30 11:42:44.978735 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Ignoring pacts explicitly specified in the selectors (none)
2023-03-30 11:42:44.979048 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Ignoring pacts successfully verified by this provider branch when not WIP (none)
2023-03-30 11:42:44.979434 D [37431:13260] [wip] PactBroker::Pacts::PactsForVerificationRepository -- Ignoring pacts successfully verified by another provider branch when not WIP (none)
It is NOT considered WIP on your main branch because you successfully verified it with an explicit selector on the matching branch.
This is how I reproduced your scenario.
Copy code
#!/usr/bin/env ruby

# The content_id is used to deterministically generate pact content. It doesn't matter what the value is.
# If you want to simulate publishing a pact that has the same content as a previous pact, use the same ID.
# If you want to simulate publishing a pact with different content, use a different ID.

#!/usr/bin/env ruby

# The content_id is used to deterministically generate pact content. It doesn't matter what the value is.
# If you want to simulate publishing a pact that has the same content as a previous pact, use the same ID.
# If you want to simulate publishing a pact with different content, use a different ID.

require "bundler/inline"

gemfile do
  source "<https://rubygems.org>"
  gem "faraday"
end

begin

  $LOAD_PATH << "#{Dir.pwd}/lib"
  require "pact_broker/test/http_test_data_builder"
  base_url = ENV["PACT_BROKER_BASE_URL"] || "<http://localhost:9292>"

  CONSUMER = "FooService"
  PROVIDER = "BarService"

  td = PactBroker::Test::HttpTestDataBuilder.new(base_url)
  td.delete_pacticipant(CONSUMER)
    .delete_pacticipant(PROVIDER)
    .create_pacticipant(CONSUMER, main_branch: "main")
    .publish_contract(consumer: CONSUMER, consumer_version: "2", provider: PROVIDER, content_id: "111", branch: "feature/fun-123")
    .get_pacts_for_verification(
      provider: PROVIDER,
      enable_pending: true,
      provider_version_branch: "feature/fun-123",
      include_wip_pacts_since: "2020-01-01",
      consumer_version_selectors: [{ mainBranch: true }, { matchingBranch: true } , { deployedOrReleased: true }]
    )
    .verify_pact(
      index: 0,
      provider_version_branch: "feature/fun-123",
      provider_version: "2",
      success: true
    )
    .can_i_deploy(pacticipant: PROVIDER, version: "2", to_environment: "test")
    .get_pacts_for_verification(
      provider: PROVIDER,
      enable_pending: true,
      provider_version_branch: "main",
      include_wip_pacts_since: "2020-01-01",
      consumer_version_selectors: [{ mainBranch: true }, { matchingBranch: true } , { deployedOrReleased: true }]
    )


rescue StandardError => e
  puts "#{e.class} #{e.message}"
  puts e.backtrace
  exit 1
end
If I remove the 
{ matchingBranch: true }
selector, and only rely on WIP to bring in that pact, then I still get the pact as WIP on the main branch.
Copy code
#!/usr/bin/env ruby

# The content_id is used to deterministically generate pact content. It doesn't matter what the value is.
# If you want to simulate publishing a pact that has the same content as a previous pact, use the same ID.
# If you want to simulate publishing a pact with different content, use a different ID.

require "bundler/inline"

gemfile do
  source "<https://rubygems.org>"
  gem "faraday"
end

begin

  $LOAD_PATH << "#{Dir.pwd}/lib"
  require "pact_broker/test/http_test_data_builder"
  base_url = ENV["PACT_BROKER_BASE_URL"] || "<http://localhost:9292>"

  CONSUMER = "FooService"
  PROVIDER = "BarService"

  td = PactBroker::Test::HttpTestDataBuilder.new(base_url)
  td.delete_pacticipant(CONSUMER)
    .delete_pacticipant(PROVIDER)
    .create_pacticipant(CONSUMER, main_branch: "main")
    .publish_contract(consumer: CONSUMER, consumer_version: "2", provider: PROVIDER, content_id: "111", branch: "feature/fun-123")
    .get_pacts_for_verification(
      provider: PROVIDER,
      enable_pending: true,
      provider_version_branch: "feature/fun-123",
      include_wip_pacts_since: "2020-01-01",
      consumer_version_selectors: [{ mainBranch: true } , { deployedOrReleased: true }]
    )
    .verify_pact(
      index: 0,
      provider_version_branch: "feature/fun-123",
      provider_version: "2",
      success: true
    )
    .can_i_deploy(pacticipant: PROVIDER, version: "2", to_environment: "test")
    .get_pacts_for_verification(
      provider: PROVIDER,
      enable_pending: true,
      provider_version_branch: "main",
      include_wip_pacts_since: "2020-01-01",
      consumer_version_selectors: [{ mainBranch: true }, { deployedOrReleased: true }]
    )


rescue StandardError => e
  puts "#{e.class} #{e.message}"
  puts e.backtrace
  exit 1
end
This is the tool I used to reproduce the issue https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
h
Yes, this is my question exactly. I feel that this particular case is easily produced when on boarding a first time provider. I get everything working by using the matchbranch selector. .. Yes it is technically a wip pact as I expect, but it is also a pending pact. And would be ideal in this case to verify it on provider main
My only way around this was to create a new consumer branch to get the pact back into unverified in order to get the provider main branch to pass
b
The answer is: you don’t need the { matchingBranch: true } if you’ve got wip pacts turned on.
h
My dup branch was never merged
Ah, I see. Let me go look at the doc again. I feel I got these selectors from a doc
What is the preferred config when no longer using tags
We use main branch as our single source
b
I would either use { matchingBranch: true } or wip, but don’t use both if you want it still to be wip on your main branch after successful verification on the feature branch.
In the second scenario where I have removed { matchingBranch: true }, the pact is still wip on main https://github.com/pact-foundation/pact_broker/actions/runs/4559431887/jobs/8043376957#step:3:1496
Please have a careful look through the code and the output.
h
Interesting. I’ll take a look probably on Friday at this point. Thanks for the follow up
👍🏼 1
👍 1
b
h
So do you conditionally define selectors on main branch differently
b
no
h
👍🏽
m
Thanks Beth, this is helpful info.
h
i think we can clarify this doc here for recommended selectors. it feels that the wip and pending pacts support is a far more valuable feature when enabled for main branch development. matchingBranch selector and enabling wip/pending seem to be mutually exclusive features???
2 Views
Open in Slack
PreviousNext
Powered by