Run hazard-linux64-haz/debug less often
Categories
(Testing :: General, task)
Tracking
(firefox79 fixed)
| Tracking | Status | |
|---|---|---|
| firefox79 | --- | fixed |
People
(Reporter: Sylvestre, Assigned: Sylvestre)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
According to https://console.cloud.google.com/bigquery?project=moz-fx-data-taskclu-prod-8fbf&j=bq:US:bquxjob_4c635c74_1727f35a25d&page=queryresults (thanks Ben), hazard-linux64-haz/debug is one of the most expensive build job.
According to
https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=WkPx8G6cRii1D4o-0C1Gaw-0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunning%2Cpending%2Crunnable&tochange=7516aaa595a0c9c7223e4281185233ca6b87a980&fromchange=72129cde7d7fe8d718ce1836bd5f016dd6808e08 (thanks Aryx), over the last 120 days, only one patch has been backout because this job failed (and the rest of the jobs have been disabled - so, maybe other jobs would have found it).
Discussing with Jonco, it is a very valuable job. So, we need to keep it running but we don't have to run it that often.
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 2•5 years ago
|
||
|
||
Comment 3•5 years ago
|
||
(In reply to Sylvestre Ledru [:Sylvestre] from comment #0)
maybe other jobs would have found it
Sadly this is not the case - this analysis finds bugs that no other jobs will find.
|
|
Assignee | |
Comment 4•5 years ago
|
||
Sadly this is not the case - this analysis finds bugs that no other jobs will find.
Sorry, my wording was terrible.
What I meant here is that hazard-linux64-haz could have failed because of a stupid build failure. linux64 opt/debug would have failed too.
I have been interested in jobs during which everything was green but only hazard-linux64-haz failed (where it has a great value)
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 5•5 years ago
•
|
||
A couple of things:
- It makes sense for the hazard build to be the most expensive build job: it has to do a full instrumented compile plus the analysis itself
- it could be sped up slightly by modifying the build system to stop after compiling (and thus skip linking)
- the compile cannot be incremental or cached with sccache; the compiler needs to generate its internal data structures for every source file in the build
- it is expected that most hazard failures will be found on the try server before they make it to autoland -- but this depends on whether people are selecting the hazard build for their try pushes. Try syntax will select it whenever
-p linux64is used, but try fuzzy won't automatically pull it in with anything else. - the hazard build catches issues that often turn out to be security flaws
It is theoretically possible to make this build incremental or even cachable, but the intermediate files are huge and it would be a fair amount of work. And if we're going to drop down the frequency, it'll stop helping anyway.
I have no reason to challenge the decision on frequency. If it only had one unique failure ("unique" as in no other job would have caught it) in the last 120 days, it totally makes sense to me to drop its frequency. As long as it ends up running on all of the code committed, it'll find everything it can find. There's no need for it to see every change individually.
|
||
Comment 7•5 years ago
|
||
Backed out for breaking Gecko Decision Task.
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=305067697&repo=autoland&lineNumber=823
Backout: https://hg.mozilla.org/integration/autoland/rev/e021e0294b0d4552816ad4741a92c37d8325f8a4
|
||
Comment 9•5 years ago
|
||
Backed out for breaking the Gecko Decision Task
Backout link: https://hg.mozilla.org/integration/autoland/rev/2e45564c1c339fda68c8a9e12f8a33fcc86c3e10
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=305234800&repo=autoland&lineNumber=824
|
||
Comment 10•5 years ago
|
||
|
||
Comment 11•5 years ago
|
||
| bugherder | ||
Description
•