smoosh jobs run, fail often, but not sheriffed
Categories
(Core :: JavaScript Engine, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | fixed |
People
(Reporter: jmaher, Assigned: arai)
References
Details
Attachments
(1 file)
I want to make sure the smoosh jobs we run in CI (mozilla-central, linux opt+debug) are providing value.
They have been running for >1 year, and so far we have sort of a high % failure rate (>25%). As they are not annotated, I don't know if we are seeing the failures and acting upon them to fix things.
since Jan 1, 2022, here are the results of smoosh tasks:
project result f0_
mozilla-central failed 180
mozilla-central worker-shutdown 15
mozilla-central completed 682
try canceled 34
try deadline-exceeded 71
try failed 214
try completed 558
try worker-shutdown 15
try claim-expired 2
these also consumed 928 hours of cpu time since Jan 1, 2022.
:arai, I see you did the initial work to create these jobs, would you be the one to comment on how useful they have been? should these become tier-2? should we stop them? is there active work?
Assignee | ||
Comment 1•2 years ago
|
||
I'm tracking the result, and each failure is handled under bug 1619282.
but I admit that most failures are also caught by https://github.com/arai-a/smoosh-sync/issues?q=is%3Aissue these days (the repository monitors changes on related files), and if we stop automatically triggering the SM(smoosh) job, I still could keep the code up to date, as long as the same job can be triggered on try, to verify the fix.
The high failure rate comes from 2 things.
- the failure cannot be fixed immediately (it starts from m-c merge, and the fix needs to be done on jspargus repo, and then the re-vendor needs to be merged to m-c)
- once or twice, I overlooked the failure keeps happening after the merge
anyway, I think we can stop the job on m-c.
Assignee | ||
Comment 2•2 years ago
|
||
Comment 3•2 years ago
|
||
(In reply to Tooru Fujisawa [:arai] from comment #1)
anyway, I think we can stop the job on m-c.
If we stop the job on m-c, then only the sync repository would remain for warning about integration issues?
So far we have no plan which seems to involve adding this new frontend to SpiderMonkey.
I know this might be a hard choice. Is this worth your time to maintain the project afloat?
Assignee | ||
Comment 4•2 years ago
|
||
(In reply to Nicolas B. Pierron [:nbp] from comment #3)
If we stop the job on m-c, then only the sync repository would remain for warning about integration issues?
Yes, I'll receive email for new issues when related files get modified.
e.g. https://github.com/arai-a/smoosh-sync/issues/274
It covers Opcodes.h
, so most changes that breaks the --enable-smoosh
build can be caught there.
The things that's not covered there are:
- some underlying change that affects frontend (in this case, the sync job needs to be updated to monitor the file)
- new syntax-related testcase that's not handled by jsparagus parser
Both will be caught in the try run for the next time Opcodes.h
or some other file gets modified.
Also, the latter case doesn't matter much, given what we'll do is simply disable the testcase.
I know this might be a hard choice. Is this worth your time to maintain the project afloat?
Monitoring the related change benefits anyway. it tells me what's going on around new feature or VM/JIT refactoring.
And in most case updating jsparagus doesn't take much time (let me know reviewing those patches takes time for you).
so I think it's fine to keep maintaining the project.
Pushed by arai_a@mac.com: https://hg.mozilla.org/integration/autoland/rev/8deefe325411 Stop SM(smoosh) jobs on mozilla-central. r=nbp DONTBUILD
Comment 6•2 years ago
|
||
bugherder |
Description
•