x/build: filter Dashboard to subsets of ports

[rorth]

This issue is with the Go Build Dashboard,
thus environment and go version info is irrelevant.

What did you do?

When looking at the Go Build Dashboard (the solaris-amd64 builder in my case), it's quite difficult
to associate a build (especially a failing one) with the corresponding commit: due to the large
number of builders now running, the page is so wide not to fit on a single screen.

What did you expect to see?

It would be very helpful to be able to select either a specific subset of builders or even a single
one, just like buildbot based dashboards allow. This would avoid the problem above and make
the display way more useful.

What did you see instead?

An extremely wide display of builders, many of which I don't know or care about: pure information
overflow, making my work unnecessarily difficult.

[ALTree]

It would be very helpful to be able to select either a specific subset of builders or even a single
one, just like buildbot based dashboards allow. This would avoid the problem above and make
the display way more useful.

IMO a better solution would be to just make the first column (the one with the commits) fixed, so that it always stays on the screen when you scroll right.

[rorth]

Alberto Donizetti <notifications@github.com> writes:

It would be very helpful to be able to select either a specific subset of builders or even a single one, just like buildbot based dashboards allow. This would avoid the problem above and make the display way more useful. IMO a better solution would be to just make the first column (the one with the commits) fixed, so that it always stays on the screen when you scroll right.

It's better than what we have now but still all those poor souls with ports off to the right of usual screen widths would have to scroll over potentially many ports of no interest to them again and again to check what's going on for the ports they care about.

[bradfitz]

How about just a GOOS and/or GOARCH URL parameter?

[rorth]

Brad Fitzpatrick <notifications@github.com> writes:

How about just a GOOS and/or GOARCH URL parameter?

Certainly fine as a first step. A selection mechanism allowing more than one of those would be nice, though (imagine solaris+illumos or freebsd+openbsd+netbsd).

[bcmills]

I still wonder if something based on Go build constraints might be useful. solaris would cover Solaris + Illumos, although I guess we don't have a build constraint that matches BSD kernels in general.

[rorth]

"Bryan C. Mills" <notifications@github.com> writes:

I still wonder if something based on Go build constraints might be useful. solaris would cover Solaris + Illumos, although I guess we don't have a build constraint that matches BSD kernels in general.

It's certainly something familiar to Go developers. If you somehow allow for the their full generality, you could easily express the *BSD example, although the syntax could become unwieldly, especially for the case of multiple constraints AND'ed together.