[Feature] GitLab group webhooks support with automatic job discovery

[Dbzman]

Is your feature request related to a problem? Please describe.
Currently we need to add webhooks to each of our GitLab projects separately because of the namespace and job parameters the operator webhook requires. This is tedious with hundreds of repositories mapped to different jobs.

Describe the solution you'd like
Add something like global webhooks which would allow to

• use group webhooks from GitLab
• auto discover the jobs where a project belongs to (job parameter is optional with this, maybe namespace as well)

[lukashankeln]

I like that idea, but there are one/two things i am thinking about, why we have not yet implemented this:

• What should we do if a repository exists in two job definitions?
  • We could just execute the first match?
• Pretty unlikely but what if there are two repositories with the same name and path in two different git-providers.

I know these are not the most likely scenarios. Happy to hear your (and everyone else`s) thoughts about this.

[Dbzman]

What should we do if a repository exists in two job definitions?

I would naively trigger all matches, which would be my definition of a group webhook anyway.

If there's a repo in multiple definitions, the user probably did that by intention. Maybe different configs with different schedules could be a reason to do so. We could think about having some kind of allow or block list for such cases, but I'm not really sure if it's worth to do so in the beginning.

Pretty unlikely but what if there are two repositories with the same name and path in two different git-providers.

The payload of GitLab webhooks include the instance url in several places. We could add some host configuration to the webhook config and check the origin whenever the webhook is called.