https://pact.io logo
Join Slack
Powered by
Also, there’s two sets of documentation in the <pa...
# pact-broker
t
Also, there’s two sets of documentation in the pact.io pages, and they don’t agree: 1) I found this first, which is what I’ve been using: https://docs.pact.io/pact_broker/advanced_topics/api_docs/publish_pact 2) There’s also this: https://docs.pact.io/pact_broker/publishing_and_retrieving_pacts#publish-using-http-requests , which leads here That second link has the 
notices
section, which I definitely want (the first API call doesn’t return the notices). However, it says it only accepts 
"specification": "pact"
. The problem I’m actually facing is that I want to mark my uploaded contract as on a particular branch/environment, which appears to only be supported on that second API call. What’s the best way to fix this? Is there a reason that 
"specification": "pact"
is the only valid type?
y
so the first page isn't linked to any nav structure in the docs hence so side bar, so I don't think that will be getting updated. Can't immediately answer your questions, will take a look at the code and report back
t
so the first page isn’t linked to any nav structure in the docs hence so side bar,
I found them both by navigating at pact.io
First one: • Go to docs.pact.io • Click “Pact Broker” • Expand “Advanced Topics” • Expand “API documentation” (not the duplicate API docs) • Click “publishing pacts” in the body of the article
m
> so the first page isn’t linked to any nav structure in the docs hence so side bar,
Tim you asked about docusaurus yesterday. One of the gripes with it is sometimes you get this. Also, the breadcrumbs inexplicably, aren’t clickable.
OK so the answer is they are both acceptable ways of publishing contracts. The new “all-in-one” endpoint is the preferred way going forward, to simplify things for clients (previous you had to call APIs in certain sequences to upload the contract, tag etc.) to ensure e.g. webhooks properly fired That is, you want what is described https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/index/publish-contracts.markdown but supporting a new contract type - “case”?
I just checked, and it does enforce the type:
Copy code
{
  "errors": {
    "contracts": [
      "specification must be one of: pact (at index 0)"
    ]
  }
}
Just spoke to Beth (she’s in the midst of a Ruby 3 upgrade for the broker, including all of the validation stuff so has been avoiding OSS slack).
She said just to set that field to 
pact
for now - it’s not actually currently used anywhere as was a bit of future proofing, and for us to raise a feature request to support other contract types.
t
hmmmm ok
That’ll work for now 👍
and for us to raise a feature request to support other contract types.
Do you want me to do this?
m
Feel free to weigh in 🙂
🙏 1
t
Thank you!
y
I'm liking where this is going! We conducted contract testing without using Pact in a previous company (prior to me knowing about it's existence) using Karate, to create mocks that were used in consumer tests, and we then validated these mocks against deployed services to check they aligned. It was more reactive, than proactive, but it worked. A huge amount of benefit with the contract testing technique comes from the addition of the broker • ensure that your contract tests have passed successfully before deploying a consumer or provider application (can-i-deploy) • ensure that the provider verification takes place every time a pact contract changes (webhooks) • ensure backwards compatibility between services is maintained (branches/tags) • allow contracts to change without breaking provider builds (pending pacts) It we could expand beyond pacts, and we can provider verification results from any type of process it expands the use cases more broadly and introduces the broker for orchestration for those unable/unwilling to use Pact. like shown here https://github.com/pactflow/pactflow-jsonschema-example#provider-test
t
Yes! Also, the broker’s ability to tell you what is deployed where is SUPER USEFUL, and could be a feature on its own - even without contract testing
1000000 1
y
last client had everything running on kube and there was a helm dashboard where you could see the versions of all the services, link to commits so you could see the build contents and roll back if you needed too. they didn’t have contract tests thing but have since brought them in
❤️ 1
6 Views
Open in Slack
PreviousNext
Powered by