feat: Support for local webhooks #61
Comments
|
@JosephKav This could also be used for the Gitea/Drone use case. I was able to setup webhook and with Drone CLI kick off a build. Would mean users maintaining scripts for each webhook (rather than just calling the native platform webhooks directly from Argus), but does not look like a large effort. If you implemented this, could probably cover a lot of uses cases where the platform has a CLI, API, etc. |
|
Did either of you try the existing config.yml webhook:
test:
type: github
url: https://FQDN/redeploy
secret: SECREThook.json [
{
"id": "redeploy",
"execute-command": "/opt/webhook/redeploy.sh",
"command-working-directory": "/opt/webhook",
"pass-arguments-to-command": [],
"trigger-rule":
{
"and":
[
{
"match":
{
"type": "payload-hmac-sha256",
"secret": "SECRET",
"parameter":
{
"source": "header",
"name": "X-Hub-Signature-256"
}
}
},
{
"match":
{
"type": "value",
"value": "refs/heads/master",
"parameter":
{
"source": "payload",
"name": "ref"
}
}
}
]
}
},
] |
|
I did try it, but without any luck. I think you are missing a In your example SECRET is representative of an random api_key? I was trying to pass in container name as the secret and ultimately an argument for the script. Not quite understanding what the second match is for. I can run this script locally |
Yup, fixed that now
SECRET is the SECRET for your webhook. You just need to give Argus the same This secret is used to create a hash signature which the receiver then checks matches with the secret they are looking for So in my example, url: https://FQDN/redeploy
secret: SECRETsends the webhook to FQDN/deploy and hashes it with SECRET. |
|
Is there a way to pass an argument so that one script is required or will we need a separate script for each with the container name/app name hard coded in the script? Not the end of the world, but it is 1 script vs. 30+ at the moment. |
I believe we'd need support for custom headers in the webhook for this "pass-arguments-to-command":
[
{
"source": "payload",
"name": "head_commit.message"
},
{
"source": "payload",
"name": "pusher.name"
},
{
"source": "payload",
"name": "head_commit.id"
}
],so when it receives a webhook from GitHub it does the following This seems to run I could work on adding webhook:
name:
url: https://FQDN/redeploy
secret: SECRET
custom_headers:
- something:
foo: bish
another: bash
- app: boshso in your case, you could have custom_headers:
- app: argus"pass-arguments-to-command": [ { "source": "payload", "name": "name" } ],to run the |
|
Would probably make sense longer term if the lift is not large. Maintaining multiple scripts is not the end of the world in my case. Each is only going to have 3 or 4 commands and most will all be the same. Could be complex I suppose depending on the use case people come up with. I do not see a -test.webhook. Is there a way to test from the Argus CLI? Using your config with a container name hardcoded in the webhook script, the webhook is sent, but it is not triggered because the trigger rules were not satisfied. My hooks.json is identical to yours except for paths and script name. webhook service log config.xml global definition config.xml service definition |
It doesn't seem like it'd be very large. Only possible issue I can think of is getting Go to handle unmarshaling the config.yml. Ideally I'd want it to be able to handle multiple levels of keys, so something like custom_headers:
foo:
a: 1
b: 2
another:
test: 123
app: nameNot sure if there'd be a use-case, but I'd like it. I think it should be pretty easy, but not the end of the world if it'll only allow
The only current way of testing would be to set the
Do you definitely have the same |
|
The secret is both argus config.xml and hooks.json is I was thinking since the webhook type in argus config.xml is github, that the second match below was being handled automatically by argus. |
so your trigger-rule matches this? It worked fine for me with the secrets as SECRET "trigger-rule":
{
"and":
[
{
"match":
{
"type": "payload-hmac-sha256",
"secret": "SECRET",
"parameter":
{
"source": "header",
"name": "X-Hub-Signature-256"
}
}
},
{
"match":
{
"type": "value",
"value": "refs/heads/master",
"parameter":
{
"source": "payload",
"name": "ref"
}
}
}
]
}
}, |
|
Yeah, I restarted the webhook service. Her si my complete hooks.json |
|
That's very odd as that exact config works with webhook:
test:
type: github
url: https://FQDN/hooks/drone-build
secret: SECRETfor me |
|
Hmmm....I just reverted my hooks.json back to my config and tested from Ubuntu CLI and I am able to trigger the webhook. So it seems like the service is working as expected. Here is that config if it is of any value. drone-buils.sh looks like this webhooks.sh looks like this: Can then execute with |
|
In my case I am unable to make it work :( I have this in the argus config.yaml: And this in hooks.yaml for webhook config (I prefer yaml to json): When I try to "resend webhooks" in argus, no update-test webhook is called, however, it seems to trigger all of the webhook-deployed ones I have. It might be something about my config but I cannot see what it is now. The deployed_version calls through webhook work fine though. |
:O didn't realise it supported yaml! Converted mine straight away XD, <3 yaml! Your config worked when I tried it though :/. |
|
So for fun (I mean who doesn't love certs), I changed webhook to use https. I get a different error in the webhook log when I execute the webhook from Argus, but I am guessing it is related to how I generated the self signed cert. Thought I would share in case it sheds any new light on the topic. webhook log cert generation command |
|
So local webhooks do currently work, you just requested support for params, which in the PR, I've enabled with support for |
|
Not from my part! Thank you @JosephKav |
|
Agreed. Good to close and thank you very much @JosephKav. |
Please consider support for local webhooks such as webhook tool. It would also be extra-useful to somehow configure argus to change an HTTP Query parameter so different services can call the same webhook with different parameters. Such as for instance:
http://192.168.9.9/hooks/update-docker?container=argus.The text was updated successfully, but these errors were encountered: