Automatic Webhook registration

[maigl]

Problem

Currently, garm does not automatically register a webhook in the org or repo. A user has to do this manually.

Idea

garm should automatically register the webhook at org or repo level.
The webhook password is automatically generated if not specified by the user.

Remarks

I already implemented a solution in my fork. I you like I could share a PR?!

_{Michael Kuhnt michael.kuhnt@mercedes-benz.com Mercedes-Benz Tech Innovation GmbH (ProviderInformation)}

[gabriel-samfira]

Hi @maigl !

We considered this when making the initial design, but we ultimately decided to add as little magic to garm as possible. The idea was to have garm be limited in scope for a few reasons:

• Security. We are fairly confident that the surface garm has is quite small, and even in the event that there is some vulnerability, there is little chance of garm being misused. To this effect, ``garm``` mostly does read-only operations, with 2 exceptions:
  • when you manually remove a runner
  • when we generate a join token for a new runner
• Transparency. We wanted the operator to be aware of the need to install a webhook. This is important for a few reasons, considering garm is self-hosted:
  • Some environments need approval before a service is exposed to the internet.
  • Firewall rules need to be added, possible reverse proxy needs to be involved, or maybe a WAF of some kind.
  • The organization may have strict rules in regards to how such a service is exposed and of how secrets are handled (webhook secret in this case).
• Simplicity. We wanted to avoid feature creeping as much as possible. If something is not absolutely necessary for garm to work, it's easier to simply create automation to fix. Especially if it's something that only needs to happen once.
• Flexibility. Because the web hook endpoint can be hidden behind a reverse proxy, there is no way for garm to know what the actual web hook URL is. The instance status callback URL is a similar case, but this one is used many times by all runners that get spawned automatically by garm, and only needs to be accessible by the runners that get spawned in the provider (it can be private and not exposed to the internet) so it was somewhat justified. The web hook URL may differ from the callback_url so we would have to add a new option in the config, simply to be able to add web hook endpoints in repos and orgs. That is not a terrible thing, but at the end of the day, if we yank out that config option and all the code needed to add the webhook to a repo/org, we would have a simple ansible playbook or abash script.

In short, I think this feature would be better implemented external to garm.

That being said, this feature makes a lot of sense if we ever decide to turn garm into a service that can easily be integrated into the GitHub marketplace. That means turning it into a hosted service that can be installed and hosted by anyone and published to the GitHub marketplace. That is something that will probably happen further down the line, if there is enough interest. As of now, the worker implementation in garm is monolithic so it doesn't really scale out. It can be changed to scale out, but at this stage it's not a priority.

I would love to hear your thoughts.

[maigl]

I understand your points quite well. The main reasons I added automated webhook creation in our instance are:

1. garm needs the webhooks for swift operation, but adding the webhooks manually is boring and error prone (yes, one only has to do it once .. but once in each repo and org .. and we many orgs :))
2. the webhook needs to be configured correctly: correct content type, correct event(s) and a password I need to know .. more room for error here

.. but you're right .. I can easily get all benefits of automatic generation with a small helper script.
Furthermore, we will register garm runners on enterprise level soon. This also reduces our needs of this feature.