build dashboard triage log #52653
Labels
Builders
x/build issues (builders, bots, dashboards)
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
umbrella
Milestone
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
(The above commands are using a |
|
Notes for today:
|
|
|
|
Notes:
|
|
|
|
Notes:
|
|
Notes:
|
|
Notes:
|
heschi
added
the
NeedsInvestigation
|
Notes:
|
|
Notes:
|
|
Observed in this batch are:
And one newly-reported issue: |
|
(4 matching logs, omitting logs processed from earlier today) |
|
Observed in this batch are: |
|
In the last triage batch, there were a couple duplicate issues filed for gopls flakes that had already been fixed (with closed issues). That's fine, I don't mind de-duping, but is there a way that I can preempt the triage process by making sure the existing issues are associated with the flakes? Perhaps a label I can add, or a particular format to the issue I create? |
|
I added a feature to greplogs to automatically resolve logs that matched a passed regex, which helped me get the list down from 500 (after omitting half a dozen builders) to ~100. I give up. |
|
Change https://go.dev/cl/425075 mentions this issue: |
That's all of the entries that were still unchecked (unless I missed one in the middle), but that 500 number is also suspiciously round. 🤔 |
|
The 500 really is just coincidence. |
gopherbot
pushed a commit
to golang/build
that referenced
this issue
Aug 25, 2022
Add a flag --known issue that associates issues with log entries based on regexp matches. It's used like this: --known-issue='#53456=TestDebugLines' Which results in the check box for that log being pre-checked, and the text '#53456' being added, which turns into a pretty link on GitHub. It might be nice to group issues as well, but I didn't want to mess with the chronological ordering. For golang/go#52653. Change-Id: If4615cd798ba72c1c1ee3cb43f1d1ad6d4319528 Reviewed-on: https://go-review.googlesource.com/c/build/+/425075 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Heschi Kreinick <heschi@google.com> Auto-Submit: Heschi Kreinick <heschi@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
|
We're now using |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We've been publishing minutes for various recurring discussions (proposal review, Go 2 review, compiler & runtime meeting notes). This issue is an attempt to apply the same pattern for builder triage.
We'll add a post here for the commands run throughout the week to triage failures on the Go build dashboard (https://build.golang.org).
For each day's triage, I first run
fetchlogsto fetch the previous day's logs (and then some, becausefetchlogsdoesn't yet have a date flag). Then, I usegreplogsto identify failures since the previous run, excluding known-bad commits and known-flaky builders.greplogs --triageoutputs Markdown containing GitHub task lists. Entries that have been triaged will be checked off the corresponding post.―
The commands to perform a typical triage run look like:
fetchlogsmay take several minutes to finish;greplogsshould be faster.If the
greplogsoutput has too much noise (such as due to a large build break or malfunctioning builder), use the--omit,--since, and/or--beforeflags to prune it down. When you've got it down to a manageable size, paste the Markdown output fromgreplogsinto a new comment on this issue.Then, check off the failures from the list as you triage them. (It's ok to leave entries unchecked if you haven't gotten to them yet, but try to finish the last run before moving on to a new one.)
The text was updated successfully, but these errors were encountered: