https://pact.io logo
Join Slack
Powered by
Hi team :slightly_smiling_face: I have some doubt...
# pact-broker
r
Hi team 🙂 I have some doubts regarding the 
Webhook
triggering. Reading the documentation here, I can see this:
If the relevant consumer version has any tags, then for each tag, check if the content is different from the previous latest version for that tag. It is 'changed' if any of the checks are true. One side effect of this is that brand new tags will trigger a pact changed event, even if the content is the same as a previous version.
Reading this, some questions come to my mind: 1. Does it work for 
branches
that way? I mean, if we used branches instead of tags, it would still trigger an execution for every new branch even if there are no changes to the contract? (Currently we are using both branch and tags) 2. Would it happen that way too with the 
contract_requiring_verification_published
event? We are still using the old 
contract_content_changed
🙂 3. Is there a way to "disable" those "side-effect" executions? I would like to avoid them if the contract does not include actual changes. 4. I'm pretty sure there is a reason why every new branch triggers an execution, but I'm struggling at understanding it 😅, because that new branch may or may not introduce actual contract changes. Could anyone help me understand that? Thank you! 🙂
b
@Rubén Pérez the docs are about to be updated. Please use the contract_requiring_verification_published event instead of contract_content_changed.
I’m pretty sure there is a reason why every new branch triggers an execution, but I’m struggling at understanding it
You may have random data in your pacts.
If the pacts are the same, then it’s most likely just the undesirable behaviour of the old webhook, and it’s one of the reasons why there is a new one to replace it.
• It only triggers if there is a verification result missing for one of the critical provider versions, reducing the number of unnessary builds triggered.
r
Hi Beth! 🙂 I guess this answers one of my questiones directly:
It only triggers if there is a verification result missing for one of the critical provider versions, reducing the number of unnessary builds triggered.
So moving to the newer event should solve our current "issue". As far as your other comments, I checked the diff to see what changed and why the webhook triggered, but in this case what I saw was pretty confusing to me. I will try to explain it. We have an issue with random data previously that we caught using that diff (you folks helped me with that previously 🙂 ), but in this case what I see in the diff doesn't make a lot of sense to me. It shows changes in the contract (real changes, no random data), but those changes are not between the code versions I'm trying to compare. It shows differences that are not actual differences in the code... so maybe I did the wrong comparison, or maybe the comparison doesn't work so smoothly when new branch/tags appear
b
the comparison doesn’t know about the branches or tags.
I’d try switching to the new webhook and see how you go.
if you still have issues, let me know
it should Just Work TM
😆 1
the main diff is that you’ll need to pass in the git sha of the provider to the build.
so that you can do builds of the prod/test/main versions etc.
r
then maybe I just got wrong the versions to compare, and hence the weird result I saw 😅 I will take a look at how to migrate to the newer event and try to do it. I already had that in my to-do list, so it's a very good time to work on it 🙂
👍🏼 1
thank you very much for the help. That was fast 😊
b
we need to start building up the webhook library for the new webhook, so if you would be able to share the webhook if you get it working that would be 🙌🏼
👍 1
need to start updating these ^^
r
that was another things I had in my to-do list xD. I was interested in the 
Github - publish commit status
and the slack notifications. As I see, the 
Travis - trigger build
is still documented using the old event... so I think now I see what you meant 🙂
would you be interested in that one if I can get it working?
b
yes please!
r
Ok, I will get back to you if I get it working. And if I have problems... I will probably get back to you too 😅 😆
😆 1
b
Any progress on this @Rubén Pérez?
r
Hi! 🙂 I had to switch to another task, but today I am going to work back on it. I'll keep you posted 🙂
👍🏼 1
I'm looking at it, but I don't really understand what I should do here. Reading the documentation, I see this:
Update the webhook body to pass in the 
${pactbroker.providerVersionNumber}
as the commit and 
${pactbroker.providerVersionBranch}
as the branch
Why do I need to send that information? I mean, what I understand is that we should check the new contract with our "main branch" version of the provider, and with the versions deployed in our defined environments (for example, production). But I'm not sure if those parameters will do the trick (not all of them are documented here)
I kind of expected the webhook to "know" what is the latest version of the provider main branch, and the latest version deployed for each environment, so it would trigger the needed builds. But I'm not really sure if I have understood this at all 😅
b
The Pact broker does know what the latest versions are, and it is triggering the right builds. But you need to pass that information to your CI/CD application, which does not know. That’s why you need to pass it via parameters in the webhook.
You need to send the commit, so the build knows which version to build. you need to send the branch because a commit might be present on multiple branches, and some CI apps like to populate the correct branch. It also helps the verification results publish with the correct branch.
r
So, let me put our scenario as an example to see if I got it right. In our case, what we want is to trigger 2 different builds of the provider: one for our 
master
branch and one for our 
production
environment (we don't have any other defined environment at the moment, as we don't think we need it). So the Pact Broker will trigger both builds (assuming both provider versions are different), and for each one it will replace those placeholders (
${pactbroker.providerVersionNumber}
and 
${pactbroker.providerVersionBranch}
) for the value they should have for those 2 different cases. Is that right?
b
Yes 👍🏼
I’ll try and update the docs to make that clearer.
r
That would be awesome 👌. Let me know if I can help you with that, because sometimes "someone from outside the project" can help with those things
b
I would love your contribution!
You just need to hit the edit button on that page, and github will do the rest.
👍 1
r
Hi 🙂 Update: I'm struggling with an Authentication issue in our Travis, that it's being hard to debug. That's why I have been a bit blocked lately. But it definitely looks like the webhook triggers the expected Travis executions as you Beth said, so as soon as I get that authentication issue fixed, I will share it so it can be included in the documentation if you want 🙂
👍🏼 1
finally
Copy code
{
	"events": [{
		"name": "contract_requiring_verification_published"
	}],
	"request": {
		"method": "POST",
		"url": "<https://api.travis-ci.org/repo/><organization>%2F${pactbroker.providerName}/requests",
		"headers": {
			"Content-Type": "application/json",
			"Travis-API-Version": "3",
			"Authorization": "token TOKEN"
		},
		"body": {
			"request": {
			"message": "Triggered by changed pact for ${pactbroker.consumerName} version ${pactbroker.consumerVersionNumber}",	
            "branch": "\${pactbroker.providerVersionBranch}",
				"sha": "\${pactbroker.providerVersionNumber}",
				"config": {
					"env": {
						"global": [
							"PACT_URL=\${pactbroker.pactUrl}"
						]
					}
				}
			}
		}
	}
}
So that's our webhook definition for Travis CI
also, I have created this PR: https://github.com/pact-foundation/docs.pact.io/pull/167 Not sure it helps too much, but I didn't come up with something better... Feel free to let me know if you want me to improve it
Open in Slack
PreviousNext
Powered by