https://pact.io logo
Join Slack
Powered by
Good morning , im review this subject : <https://d...
# pact-broker
y
Good morning , im review this subject : https://docs.pact.io/pact_nirvana/step_4#consumer-pipeline . 1. How we determine if the contract has been change ? 2. Its look like we always publishing the contract - there is a best practice how to determine it ? 3. We are publishing a lot of versions of the contract - there is a way to make sure they will delete after a while as part of the publish 4. Why we have 2 times tags (if the contract was not change between the isolated test and the integrated test) . 5. The tag purpose is to find a version of fix branch like master ? 6. In case we can use our eco system don't using the webbook - the best way it fail the ci and we invoke the the verifiers ? keep in mind im reading a lot of content from the docs 🙂.
m
Hello!
1. You don’t, the Pact Broker will determine that. You would usually use the https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event event to trigger a build based on changes to a contract that require a verification
2. It’s the best practice to always publish (not from dev, but from CI). What do you mean by “best practice how to determine it?“. What is “it” in this case?
3. If you are running your own broker, you can run https://docs.pact.io/pact_broker/administration/maintenance. If you use PactFlow, we do that automatically.
4. I’m really sorry, the advice in this guide is still outdated because it uses tags. Really you want to use https://docs.pact.io/getting_started/conceptual_overview#branches--environments. Wherever you see the use of a tag in this guide, you can assume it’s either used to represent a “branch” or represent a “deployment”. If you’re just starting, you don’t want to use tags if you can avoid it. But to answer - the reason you tag twice. The first time says “this pact represents a branch / feature I’m working on”. The second one represents “I’ve deployed this application to <environment>“.
5. Yes. We call the general concept here “selectors”: https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors
6. Yes, if you don’t use the webhook you won’t get some optimisations. But it can still work without them. And yes, I would tend to fail the build if the contract tests don’t pass or 
can-i-deploy
is failing (but that assumes a lot about how your pipeline is setup, and that is a dangerous assumption!)
y
@Matt (pactflow.io / pact-js / pact-go) 1&2. I will review it - but in a brief my question was if there is a way to determine if contract was change without publish it to reduce the publish actions - to compare generated contract with latest master branch. 3.I will review it 🙂 4.Im using branches + versions(the last commit sha as version) - but my question how to "merge" - make a contract as master ? (or its literally like any other pr - it will run the ci ) 5.Got it. 6.Ok
đź‘Ť 1
m
1. May I ask why you need it? There are APIs in Pact Broker, and obviously you have source control if needed
4.Im using branches + versions(the last commit sha as version) - but my question how to “merge” - make a contract as master ? (or its literally like any other pr - it will run the ci )
Exactly. When you merge the PR, you’ll run another build and when you publish it with the 
--branch
option, it will effectively “merge” this over the previous one (not technically, accurate, but I think you get the concept)
Open in Slack
PreviousNext
Powered by