Closed
Bug 1410911
Opened 7 years ago
Closed 7 years ago
test-verify/jsreftest/jittest runs too often
Categories
(Firefox Build System :: Task Configuration, task)
Firefox Build System
Task Configuration
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gbrown, Assigned: dustin)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
Since approximately bug 1403322, test-verify (TV) runs on every push (unless the build has been coalesced or otherwise excluded), rather than only when a .html/.js/.xul/.xhtml file is modified.
Reporter | ||
Comment 1•7 years ago
|
||
A quick but speculative fix. This does no harm:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=0d9634fac5f86fdf981b84a3340133b8d0b9ba2e
and I prefer having just the one "test-verify" name in play, but I don't know if it eliminates the extra runs.
Attachment #8921116 -
Flags: review?(dustin)
Assignee | ||
Comment 2•7 years ago
|
||
Comment on attachment 8921116 [details] [diff] [review]
use 'test-verify' consistently
Review of attachment 8921116 [details] [diff] [review]:
-----------------------------------------------------------------
Sorry, I think that was my fault.
Attachment #8921116 -
Flags: review?(dustin) → review+
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/37db725b2308
Only run test-verify when certain file types are changed; r=dustin
Reporter | ||
Updated•7 years ago
|
Keywords: leave-open
Reporter | ||
Comment 4•7 years ago
|
||
It looks like my change is not fixing this problem. (But I don't mind keeping it / no need to backout.)
Looking more closely, other test suites, like jit and jsreftest, are also running on most pushes, seemingly regardless of which files have changed. I think it is a regression from bug 1403322, but I don't see what's going wrong.
Consider:
https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=jsref&tochange=1da1df814ad3bcb7aefb5f2c00c18b3c55f72284&fromchange=4dc78384cb58c67de770ef207bbd700e7a982960
:dustin -- Can you take this?
Flags: needinfo?(dustin)
Assignee | ||
Comment 5•7 years ago
|
||
I'm at a meeting all week, so not quickly.
It might be a start to look at the SCHEDULES components that are determined in the decision task -- do those include test-verify more often than they should?
Flags: needinfo?(dustin)
Comment 6•7 years ago
|
||
bugherder |
Reporter | ||
Comment 7•7 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] from comment #5)
> It might be a start to look at the SCHEDULES components that are determined
> in the decision task -- do those include test-verify more often than they
> should?
I'm not sure I know how to answer that.
I had a look at SkipUnlessSchedules' should_remove_task(). For a push with only a couple of python files modified, and considering a task like "test-linux64/opt-test-verify-e10s", should_remove_task() sees:
scheduled == set([u'robocop', u'geckoview', u'reftest', u'web-platform-tests', u'macosx', u'talos', u'cppunittest', u'awsy', u'mochitest', u'web-platform-tests-reftests', u'web-platform-tests-wdspec', u'linux', u'telemetry-tests-client', u'windows', u'marionette', u'firefox-ui', u'gtest', u'xpcshell', u'android', u'xpcshell-coverage'])
conditions == set(['test-verify', 'linux'])
so scheduled & conditions == set(['linux']) and should_remove_task() returns false.
Reporter | ||
Updated•7 years ago
|
Summary: test-verify runs too often → test-verify/jsreftest/jittest runs too often
Comment 8•7 years ago
|
||
I have a feeling that we can't combine SCHEDULES.inclusive with SCHEDULES.exclusive. Consider test-verify. It has a it's own SCHEDULES.inclusive tag which should govern when it gets optimized or not. However, it also has an OS family (one of linux, macosx, windows or android). This means that this statement will always return True and the task will never be optimized:
https://dxr.mozilla.org/mozilla-central/source/taskcluster/taskgraph/optimize.py#386
Maybe there's something clever we can do here to better distinguish between inclusive and exclusive components, but maybe the cleanest option is to have two separate optimization: "skip-unless-schedules-exclusive" and "skip-unless-schedules-inclusive", and each task would need to decide which one to use.
Reporter | ||
Comment 9•7 years ago
|
||
I had thought that we might be able to just change:
scheduled = self.scheduled_by_push(params['head_repository'], params['head_rev'])
conditions = set(conditions)
- # if *any* of the condition components are scheduled, do not optimize
- if conditions & scheduled:
+ # if *all* of the condition components are scheduled, do not optimize
+ if conditions & scheduled == conditions:
return False
Indeed, that seems to fix the jittest and jsreftest cases, and possibly some test-verify issues.
But, especially with test-verify, there can be a conflict between inclusive and exclusive. For instance, testing/mochitest has
SCHEDULES.exclusive = ['mochitest', 'robocop']
But that directory also contains .js/.html test files that should trigger test-verify:
with Files("**/*.js"):
SCHEDULES.inclusive += ['test-verify']
with Files("**/*.html"):
SCHEDULES.inclusive += ['test-verify']
and that gets confusing:
mach file-info schedules testing/mochitest/tests/Harness_sanity/test_spawn_task.html
robocop, mochitest
Comment 10•7 years ago
|
||
Yeah, `conditions & schedules == conditions` won't work. I stared at this for quite some time and I'm pretty sure the only way to properly solve it is to split inclusive and exclusive into two separate optimizations.
Assignee | ||
Comment 11•7 years ago
|
||
Your reasoning makes sense, and I feel silly for not seeing it.
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Comment 12•7 years ago
|
||
:dustin - It sounds like you are the best person for this...hope you have the time.
Assignee: gbrown → dustin
Reporter | ||
Comment 13•7 years ago
|
||
We continue to run lots of unnecessary tests -- Android jsreftest alone is an extra 140 tasks per push on central (mitigated by SETA elsewhere).
Can we back out bug 1403322, or fall back to when: files-changed?
Flags: needinfo?(dustin)
Assignee | ||
Comment 14•7 years ago
|
||
If you think that's not too risky right now, please feel free.
Flags: needinfo?(dustin)
Comment hidden (mozreview-request) |
Reporter | ||
Comment 16•7 years ago
|
||
mozreview-review |
Comment on attachment 8927400 [details]
Bug 1410911 - back out bug 1403322;
https://reviewboard.mozilla.org/r/198704/#review203820
Thanks. This looks right.
I think the reward justifies the risk here, but you have a more complete perspective: I understand if you want to wait before checking in.
Attachment #8927400 -
Flags: review?(gbrown) → review+
Comment 17•7 years ago
|
||
Pushed by dmitchell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c1848b8de242
back out bug 1403322; r=gbrown
Comment 18•7 years ago
|
||
Assignee | ||
Comment 19•7 years ago
|
||
OK, the complaint of this bug was fixed by the backout. I'll re-land in bug 1403322, with the fix in bug 1426254.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment 20•7 years ago
|
||
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
Updated•7 years ago
|
Product: TaskCluster → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•