Open DaedalusG opened 2 years ago
Hey, @sourcegraph/batchers (@eseliger @LawnGnome @courier-new @adeola-ak @BolajiOlajide @Piszmog @malomarrec @chrispine @danielmarquespt) - we have been mentioned. Let's take a look.
Feels like this could use a spike to understand how different GHE global webhooks look/behave, if they have the same coverage as normal org ones (seems like the answer is yes if they can "subscribe to the organization" but I don't just want to assume that they're 1:1 with per-org webhook events), and how much work it would take to support them.
GHE global webhooks would impact strategic customers with many orgs to manage, so this seems like something that could be worth prioritizing if the spike reveals it wouldn't take too long to support.
Oh I investigated this in response to some support request recently and the GHE global webhooks are confusingly not the same webhooks, it's for GHE events, not PR/issue events :|
Oh really? That's too bad. 😞 Does that mean we should interpret this line ("Global webhooks can subscribe to the organization, user, repository, team, member, membership, fork, and ping event types.") as it cannot subscribe to PR/issue event types? I had thought maybe they were considered a subset of org events, based on Warren's comment, but I didn't really look into it.
Sounds like this is a non-starter and should probably be closed, then?
Maybe I understood it wrong, but AFAIK it can only inform about Repo create, user create etc events, essentially audit log events. I think we should still investigate if there are better ways (ie us automatedly creating webhooks, github apps solving that ootb, etc) but it's likely going to be backlog. WDYT?
Yeah probably. Though if https://github.com/sourcegraph/sourcegraph/issues/40939 is high priority and we agree webhooks are core to that, some automation here or the ability to use global webhooks would actually be a massive value add to customers with >10 orgs using batch changes.
Also feels backloggy to me for now — there's probably a broader "make Sourcegraph do smart things if you connect it as a full blown GitHub App" ticket somewhere that this is really a part of.
I wonder if this should get a strategic-ready label. @malomarrec WDYT? Until we hear more feedback, still feels like backlog.
Feature request description
The current method for configuring webhooks requires users to create a webhook per an org in a codehost. For example in Github:
Is your feature request related to a problem? If so, please describe.
Some Sourcegraph users belong to a company with many (#orgs>= 250) Sourcegraph Orgs, some method to simplify the process of adding many orgs to Sourcegraph would be nice.
Describe alternatives you've considered.
For GHE users a global Webhooks exist, however this webhook type currently isnt supported with batch changes, since Global webhooks are mostly for instance level events and many of the event triggers required by Sourcegraph aren't covered.
From the github documentation
For a list of events Sourcegraph handles from github see this code snippet
Additional context
At first blush it looked like global webhooks might just work with Sourcegraph so we tried them out. Unfortunately Initial testing with global webhooks shows that they aren't currently compatible with Sourcegraph