Decommission all WebhookRouter tool downstream consumers and then the tool itself

[konrad-jamrozik]

Status as of 1/25/2023: this issue is currently BLOCKED. See this comment why.

WebhookRouter tool should be decommissioned. I made an attempt of doing that here:

• Delete obsolete WebhookRouter tool #4966

However, investigation by @hallipr, @benbp and me has shown that:

• the WebhookRouter is still in use and it is routing the webhook calls into several event grids, as captured by the discussion in the above-linked PR.
• in particular, the legacy Check Enforcer still uses it, so it needs to be decommissioned first before we can decommission the WebhookRouter. This work is captured by Migrate azure-dev repo to use the new Check Enforcer and decommission the obsolete CheckEnforcer tool #4991.

Once we ensure the WebhookRouter is no longer in use, we should decommission it by doing the following:

• delete the source code and pipeline as proposed by Delete obsolete WebhookRouter tool #4966;
• update all docs by either deleting mentions of WebhookRouter, or clearly denoting it is decommissioned and no longer in use;
• delete the GitHub app. See this and surrounding comments.

[kurtzeborn]

CheckEnforcer and PipelineWitness are off of this now. We should be good to do this now.

[konrad-jamrozik]

CheckEnforcer and PipelineWitness are off of this now. We should be good to do this now.

@kurtzeborn per my comment here:

• Delete obsolete WebhookRouter tool #4966 (comment)

I do see that issuelabeler appears to be still a recipient of messages from WebhookRouter. I have problem tracing down the origin and sources of that resource group. I queried its Application Insights and I see logs like downloaded ml model, IssueLabeler or ! IssuePredEngine loaded.. I've searched some of our repos for these strings but nothing comes up (update: the repo is dotnet/issue-labeler). I

@jsquire @christothes folks, you seem to be owners of this. Can you chip-in? Can this tool be deprecated? We are trying to deprecate WebhookRouter which sends messages to issuelabeler.

If so, is there relevant source code that should also be expunged?

[konrad-jamrozik]

CheckEnforcer and PipelineWitness are off of this now. We should be good to do this now.

@kurtzeborn @benbp appears to me that checkenfrocerprod and checkenforcerstaging resource groups are still there.

Can they now be deleted?

If you are unsure, I am happy to investigate. But I am asking in case you already know.

Note this question is relevant for this comment too:

• Migrate azure-dev repo to use the new Check Enforcer and decommission the obsolete CheckEnforcer tool #4991 (comment)

[benbp]

@konrad-jamrozik they can be deleted.

[konrad-jamrozik]

@christothes @JoshLove-msft Do you know if GitHubWebHooks and the GitHubNotifications resource group from Azure SDK Developer Playground subscription can be decommissioned? I am asking you because I see you are owners of GitHubWebHooks.

If so, is there some related source code that should also be expunged?

[christothes]

CheckEnforcer and PipelineWitness are off of this now. We should be good to do this now.

@kurtzeborn per my comment here:

• Delete obsolete WebhookRouter tool #4966 (comment)

I do see that issuelabeler appears to be still a recipient of messages from WebhookRouter. I have problem tracing down the origin and sources of that resource group. I queried its Application Insights and I see logs like downloaded ml model, IssueLabeler or ! IssuePredEngine loaded.. I've searched some of our repos for these strings but nothing comes up. I

@jsquire @christothes folks, you seem to be owners of this. Can you chip-in? Can this tool be deprecated? We are trying to deprecate WebhookRouter which sends messages to issuelabeler.

As I understand it, there is a replacement coming for issue labeler. What is the timeline for that? In lieu of that happening in the short term, is there a replacement available for webhookRouter?

[christothes]

@christothes @JoshLove-msft Do you know if GitHubWebHooks and the GitHubNotifications resource group from Azure SDK Developer Playground subscription can be decommissioned? I am asking you because I see you are owners of GitHubWebHooks.

If so, is there some related source code that should also be expunged?

For GithubNotifications, I think I am the only user - what is the new recommended approach for receiving webhooks from our GitHub repos?

[konrad-jamrozik]

@christothes

As I understand it, there is a replacement coming for issue labeler. What is the timeline for that? In lieu of that happening in the short term, is there a replacement available for webhookRouter?

Do you perhaps refer to this?

• The template for prepare-pipelines is broken by the move to ubuntu-22.04 #4888 (comment)

Quoting that comment here, from @jsquire:

Context:
We're currently only using it for label synchronization, which I need to rewrite to use the GH CLI at some point. Killing off GH Creator will give me a forcing function to prioritize doing so.

If this is unrelated, sorry for the confusion! If it is related, then looks like it is on @jsquire agenda to implement a replacement.

For GithubNotifications, I think I am the only user - what is the new recommended approach for receiving webhooks from our GitHub repos?

Let me defer to @benbp to answer this.

[christothes]

@christothes

As I understand it, there is a replacement coming for issue labeler. What is the timeline for that? In lieu of that happening in the short term, is there a replacement available for webhookRouter?

Do you perhaps refer to this?

• The template for prepare-pipelines is broken by the move to ubuntu-22.04 #4888 (comment)

Quoting that comment here, from @jsquire:

Context:
We're currently only using it for label synchronization, which I need to rewrite to use the GH CLI at some point. Killing off GH Creator will give me a forcing function to prioritize doing so.

If this is unrelated, sorry for the confusion! If it is related, then looks like it is on @jsquire agenda to implement a replacement.

I believe these are unrelated. Issue Labeler is an AI based bot service that auto-assigns service labels for newly created issues.

[jsquire]

To add context, the Issue Labeler is part of our triage process for incoming issues which is specifically orchestrated to integrate into the Fabric Bot flow. Once the new automation platform that Jim is working on is complete, the Issue Labeler integration will shift to a direct API call and we'll no longer need the web hook.

For now, can we keep the web hook active?

[konrad-jamrozik]

To add context, the Issue Labeler is part of our triage process for incoming issues which is specifically orchestrated to integrate into the Fabric Bot flow. Once the new automation platform that Jim is working on is complete, the Issue Labeler integration will shift to a direct API call and we'll no longer need the web hook.

For now, can we keep the web hook active?

@jsquire @kurtzeborn @christothes @benbp @weshaggard OK so this decommission of WebhookRouter is blocked until the general work thread of the following work item is deployed to production:

• Implement existing fabricbot rules using github actions. #4478

But I am still unclear if we have a path for decommissioning/replacing this:

For GithubNotifications, I think I am the only user - what is the new recommended approach for receiving webhooks from our GitHub repos?

[christothes]

But I am still unclear if we have a path for decommissioning/replacing this:

For GithubNotifications, I think I am the only user - what is the new recommended approach for receiving webhooks from our GitHub repos?

Taking this specific tool out of the discussion, I'm curious what our plan around tooling that consumes GitHub webhooks would be going forward. WebHookRouter was great because it decoupled GitHub organization administration from webhook management, and also allowed us to treat webhooks like a pub/sub service, rather than having to configure the repo for each consumer.

[benbp]

@christothes we are moving towards github actions based for event processing as opposed to a service that receives webhooks. This has a couple pros and cons:

Pros:

• We don't have to manage services - less work around monitoring/deployment/etc. and less vulnerability to azure outages
• Throttling is less of a concern as operations are scoped per-repository and with different throttling limits from the built-in github action token, rather than using one identity for all requests
• Discoverability of event processing is easier for users, as it's linked to the action logs
• Webhook delivery is less of a concern
• Simpler architectures. We can write CLI tools instead of servers.

Cons:

• Testing and flighting of changes is harder to orchestrate
• Dependencies and/or binary size need to be minimal to limit action run time
• Responsiveness is slower and gated by runner spin-up time, binary downloads, etc. (10-20s) whereas webhooks only took a couple seconds

As far as repo configuration, the approach we're taking is standardizing github action yaml configs and mirroring them across the repos. This is a lot easier to do than manage webhook configurations through the admin portal of all repositories.