https://pact.io logo
Join Slack
Powered by
Trying to re-take the pact workshop <https://docs....
# documentation
b
Trying to re-take the pact workshop https://docs.pactflow.io/docs/workshops/ci-cd/set-up-ci/configure-consumer-and-provider-pipelines *without cleaning up the broker is causing some issues I suspect. Is there a way to reset a broker?
b
Yep. Go into the HAL browser (click the API button in the top right) and send a POST request to 
/integrations
it’ll remove all pact related data but keep environments and webhooks.
m
Post or delete?
b
oh, sorry, 
DELETE
!
❤️ 1
thanks matt.
👍 1
m
Would it be easiest to just delete the main integrations from the UI?
✔️ 1
b
that will do the same thing. just need to delete the integration.
as in, not just “delete pacts”
b
I did delete the pacts in the UI, then i deleted the integration in the UI. When i went to the HAL browser to look for anything left around, i found lots of stuff ie. pacticipants
b
try the /integrations DELETE then.
❤️ 1
b
Ya using that method, all pacticipants are also removed. thx!
Oh ya that did delete everything. Nice
except: environments
secrets
b
yeah, I was just looking at the code and realised that.
it won’t delete secrets, because that’s a pactflow feature, and the endpoint in the oss code, so doesn’t know about secrets.
b
my workshop provider build is failing in the test job with
Copy code
FAIL src/product/product.pact.test.js
  ● Pact Verification › validates the expectations of ProductService
...
 /home/runner/work/example-provider/example-provider/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.83/pact/lib/vendor/ruby/2.2.0/gems/pact-1.62.0/lib/pact/hal/entity.rb:102:in `assert_success!': Error retrieving <https://b1alpha.pactflow.io/pacts/provider/pactflow-example-provider/for-verification> status=404  (Pact::Hal::ErrorResponseReturned)
b
does the provider exist with that name?
b
I have not got to a step in the workshop, where I would have configured anything other than the PACT_BROKER_BASE_URL
its a fresh forked version of the example workshop repo, it is suppose to just pass at this point with only a the PACTFLOW_TOKEN_FOR_CI_CD_WORKSHOP setup in github
does b1alpha.pactflow.io exist yes
b
the provider application needs to exist in your pactflow account before you can run the verification step.
are you sure it’s meant to pass at that point? or is it just needing to run to prove it has connectivity?
b
Might be worth giving the workshop a shot to reproduce. It’s the first step, fresh workshop repos, fresh broker.
b
have you published the pacts already?
the consumer build needs to go first
b
okay let me check that
b
from the 404 error, I can see that the provider does not exist in that account.
b
message has been deleted
so we have a published pact here
👍🏼 1
ohhh, damn
I ran this a number of times, i must of deleted the pacts afterwards cleaning up. Thank you. Wow its EOD I am tripping out.
😆 1
Thank you for your patience
b
😆 time for a break!
b
Is there a reason we dont launch the webhook on the provider from our consumer directly, so we can wait for it to complete? Rather than asking pactflow to trigger webhooks? Seems like it would solve for this
this being the way we have to have a failing state in the consumer, then observe the provider, then run the consumer again
b
you can wait for the provider’s tests to finish by using the polling feature of can-i-deploy.
The webhooks (especially tne new one) are more complex than just “trigger a build”. You only need to trigger a build when the pact has changed, and you want to trigger multiple builds - one for each environment that the provider is deployed to, and one for the latest on the main branch.
m
Is there a reason we dont launch the webhook on the provider from our consumer directly, so we can wait for it to complete? Rather than asking pactflow to trigger webhooks? Seems like it would solve for this
It’s not the common use case, but worth considering the situation where your provider also is a consumer of another provider…..and so on. Personally (not a Pactflow viewpoint) I prefer my pipelines to be shorter, and fail in those kinds of cases, rather than wait indefinitely for something to happen or not happen.
❤️ 1
b
typically, you shouldn’t need the wait option, because the recommended workflow is to do all the changes to the consumer contract on a branch (if you use branches) so that by the time you merge, the contract is already “pre-verified” and you don’t need to wait for another verification to run.
👍 2
3 Views
Open in Slack
PreviousNext
Powered by