Include valgrind-linux runs in TBPL



Tree Management Graveyard
7 years ago
3 years ago


(Reporter: njn, Unassigned)





(1 attachment)



7 years ago
Bug 493791 added a valgrind-linux configuration to tinderbox.  It runs periodically.  It would be great if this configuration could be included in TBPL output.  The letter 'V' appears to be free :)
This really needs some new UI, for "things which don't particularly have anything to do with the push which they built, where failure doesn't close the tree."
Why doesn't failure close the tree?
Hypothetical future where it would be okay for it to close the tree: I push to try, it fails, I go read the docs on how to run it myself and either do that or debug with try if I only have Windows.

Actual present: I push to try, everything's green, I push to the Places tree, everything's green, Places merges to mozilla-central, everything's green, we all go home, the once-a-day timer fires at 17:30 and then sometime later there are five idle slaves so the valgrind build runs, and Europe gets a closed tree until someone backs out the entire merge or maybe every single thing that landed since the last valgrind run because they can't tell what caused it (I don't have any idea how obvious it will be since I've never seen a failure other than the current permared linux64 which looks like maybe it's something in libgdk or X that didn't get suppressed or maybe not, dunno), and then... do they open, even though it'll be another 24 hours before they see whether their backout was successful, or do we stay closed for 24 hours? And then when I wake up and find that I broke the tree, I go read docs that sound like someone's jotted notes from having gotten something to mostly work once, and I install a particular version of Linux so I can get a suppression file that will quiet the known noise, and since "Jesse has one somewhere..." I email him to find out where it is...

I don't know whether or not we will someday want to have valgrind close the tree, but it certainly can't with a once-a-day mozilla-central-only run, and the way releng keeps spinning up things from this once-a-day to Jetpack's every-push but not currently acceptable as a mozilla-central-closer to the once-a-week addons talos runs on 1.9.2 makes me think we need some UI and backend that I can't quite imagine to display results that may or may not be at all related to a push you're seeing, that aren't tree-closing, but just something you might want to know about.
Thanks, that was very enlightening.

I guess giving it the V letter doesn't hurt as long as it's not unhidden. Then it doesn't confuse people who run tbpl with noignore=1.
Created attachment 499080 [details] [diff] [review]
V for Valgrind
Attachment #499080 - Flags: review?(philringnalda)
Started a .tree-management thread at to figure out what we want to do with them. If we're really going to stick with the once-a-day thing, we're arguably better off not hiding them in tinderbox (where nobody ever looks, so they can be red without closing the tree) and having them not show in tbpl.
Comment on attachment 499080 [details] [diff] [review]
V for Valgrind

You're glad not to have heard weeks of conversations with myself about this, but the bottom line is that whatever we should be doing with it, setting tree policy based on what tbpl does and does not know well enough to pick a letter for is not one of the things we should be doing. When someone doesn't like the next unfiled red that they see (since we've been ignoring it for days now), they can decide what to do instead.
Attachment #499080 - Flags: review?(philringnalda) → review+
Last Resolved: 7 years ago
Resolution: --- → FIXED


3 years ago
Product: Webtools → Tree Management


3 years ago
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.