Add grouping for HUD View

[zengk95]

See title

Test Plan:
Manually verified that it works.

Screen.Recording.2022-02-14.at.10.55.53.AM.mov

Main questionable things:

1. Clicking on a grouped cell doesn't expand it, it just opens up a hover tip card that tells you which jobs are failed or pending.
2. The way that we classified a failing grouping (in this one, we considered a cancelled job as failed group)
3. Probably should have moved the grouping logic/parsing into the API
4. Filtering doesn't work very well. You need to expand it to filter out specific jobs or uncheck grouped view
5. Group view check box. I think most people tend to just view it as a group anyways so we don't necessarily need to give users this type of flexibility.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/torchci/torchci/2WiC4oLteFXgZcN3SzViNy4irXHi
✅ Preview: https://torchci-git-add-groups-torchci.vercel.app

[janeyx99]

1. Clicking on a grouped cell doesn't expand it, it just opens up a hover tip card that tells you which jobs are failed or pending.

This is totally fine; I prefer this anyway.

2. The way that we classified a failing grouping (in this one, we considered a cancelled job as failed group)

This is 100% correct since nothing should be canceled on trunk/release/nightly.

3. Probably should have moved the grouping logic/parsing into the API

lol

4. Filtering doesn't work very well. You need to expand it to filter out specific jobs or uncheck grouped view

Oh hm. Will this be improved in a later PR?

5. Group view check box. I think most people tend to just view it as a group anyways so we don't necessarily need to give users this type of flexibility.

Yea, though doesn't hurt to have?

[zengk95]

1. Clicking on a grouped cell doesn't expand it, it just opens up a hover tip card that tells you which jobs are failed or pending.

This is totally fine; I prefer this anyway.

2. The way that we classified a failing grouping (in this one, we considered a cancelled job as failed group)

This is 100% correct since nothing should be canceled on trunk/release/nightly.

3. Probably should have moved the grouping logic/parsing into the API

lol

4. Filtering doesn't work very well. You need to expand it to filter out specific jobs or uncheck grouped view

Oh hm. Will this be improved in a later PR?

5. Group view check box. I think most people tend to just view it as a group anyways so we don't necessarily need to give users this type of flexibility.

Yea, though doesn't hurt to have?

Yea I will address them in followup PRs. I think this works OK for now though.

5. It doesn't hurt to have but just has a bunch of unnecessary code to differentiate between the two views.

[suo]

Group view check box. I think most people tend to just view it as a group anyways so we don't necessarily need to give users this type of flexibility.

@mruberry, @ngimel, @albanD are we okay with landing this without a "don't use groups" view, or do you prefer that we add one first.

[zengk95]

9.

I might not have been clear, but there is a "dont use group" view checkbox at the top, near search bar that shows you basically the old version.

[albanD]

I think it's fine yes. Unless you have a crazily wide screen, it is pretty unreadable without it :D

[suo]

Can we get less horizontal space between grid columns? Right now, if I expand "linux" jobs, I can't see them all, even on my relatively large external monitor (which previously could fit all jobs)

[zengk95]

Can we get less horizontal space between grid columns? Right now, if I expand "linux" jobs, I can't see them all, even on my relatively large external monitor (which previously could fit all jobs)

Sounds good. I added spacing because I felt that the jobs names were overlapping with each other.

[suo]

I think we should come up with a more maintainable way of grouping jobs; a collection of regexes is likely to break over time and requires changes to the HUD to change the groups.

Should we enforce some convention on CI names and group on that basis? For example, we could do: - separated, from least specific grouping to most specific. e.g. linux-py3.7-cuda10.3, linux-py3.7-cpu-clang12, linux-py3.7-cpu-gcc7.3. This code could then be turned into name.split("-")[0], and eventually we can build a tree-ish structure similar to https://ci.chromium.org/p/chromium/g/main/console. Thoughts?

[zengk95]

I took this from the old HUD just to keep parity between the two. I think changing the names is a good idea since some of the workflows and stuff have different naming standards like some of the builds vs publish to s3 or something. It might also allow for better classification/parsing and stuff like how you described but it seems a bit out of scope.

[zengk95]

Just made it
pytorch/pytorch#72814

One more followup: right now the logic for collapsing groups is wrong; if I have multiple groups open and collapse one, they will all collapse. Clicking to collapse a group should only collapse that group.

[suo]

Sounds good. I added spacing because I felt that the jobs names were overlapping with each other.

yeah, I do agree that the group names look a little crowded. Ideally we can have different spacing for the group columns vs. job columns, maybe as a followup

re: overall naming/regex thing. I agree it shouldn't be blocking. Can you file an issue so we track the followup?

[suo]

One more followup: right now the logic for collapsing groups is wrong; if I have multiple groups open and collapse one, they will all collapse. Clicking to collapse a group should only collapse that group.

[mruberry]

As long as we can expand the tabs and they enumerate the jobs in their own columns this seems like a fine default