[bots] Move the disable json generation to be in HUD

[clee2000]

We get the list of disabled/unstable test/jobs in a python script, but there is code that parses the same thing in javascript for the bot that comments on all disable/unstable test/job issues, so this removes the python script in favor of a new javascript script that reuses the code used for verifyDisableIssue to generate the disable/unstable test/job jsons.

I broke the unstable/disable job json generation in #6096, so it's actually been empty since then. We've been getting by, and this PR restores it, but I wonder if this just means we can get rid of it

Pros:

• less dup code
  • string parsing for title to decide which type of issue it is
  • string parsing for body to figure out what the platforms are/what the tests are

Cons:

• it wasn't broken
• stuff that wasn't dup and had to be rewritten:
  • generating json objects of the correct shape; merging issues/platforms for the same test if necessary
  • querying graphql for list of issues
  • some parsing for unstable/disable job issues

CI is broken on this PR because it calls an API that this PR adds (which basically means this isn't really testable in CI anymore... but also given that I broke some things months ago and didn't notice, the e2e for this is probably not great in the first place). I tested locally with localhost and with the preview and it looks fine to me

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
torchci	✅ Ready (Inspect)	Visit Preview	May 31, 2025 4:26am

[ZainRizvi]

I appreciate the context in the PR description, but since this is a pretty big change having a bit more of the architecture delta described would be really helpful.

As someone rusty on how the disable logic worked, details that would help grok the changes more easily include:

• What logic was already duplicated in HUD? It looks to me like the json generation is still going to be triggered by the same workflow, but instead of executing that code locally it's now going to make an API call to hud and have hud do the work instead.
• You mentioned removing code duplication, but at a quick glance it looks like logic is being moved from one place to another. What part of the logic already existed in HUD and is now being de-duplicated?
• Correspondingly, can you summarize the logic that's actually being moved over to HUD? (the part that wasn't duplicated and thus needed to be re-implemented in typescript?)

Finally:

• Re: this change not being testable in CI anymore...that is sad. Since it's depending on a new endpoint, it's understandable that your CI fails, but it would be really nice to have enough unit testing infra in place that we can get a pretty good signal on any future changes to this code. I would hope this to be the only PR that this workflow is red on.

[clee2000]

• What logic was already duplicated in HUD? It looks to me like the json generation is still going to be triggered by the same workflow, but instead of executing that code locally it's now going to make an API call to hud and have hud do the work instead.
• You mentioned removing code duplication, but at a quick glance it looks like logic is being moved from one place to another. What part of the logic already existed in HUD and is now being de-duplicated?
• Correspondingly, can you summarize the logic that's actually being moved over to HUD? (the part that wasn't duplicated and thus needed to be re-implemented in typescript?)

added to pr body

• Re: this change not being testable in CI anymore...that is sad. Since it's depending on a new endpoint, it's understandable that your CI fails, but it would be really nice to have enough unit testing infra in place that we can get a pretty good signal on any future changes to this code. I would hope this to be the only PR that this workflow is red on.

Added unittests for the typescript

[huydhn]

LGTM!