Optimize away build tasks for test-only changes
Categories
(Firefox Build System :: Task Configuration, enhancement)
Tracking
(Not tracked)
People
(Reporter: catlee, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Once we have test packages split out from the build, or are checking out the source directly on the test machines, we can stop performing builds for test-only changes.
The scheduling logic should determine that only tests are being changed, and then optimize out build tasks, referencing the most recent non-test-only builds.
This is very similar to 1561423, the main difference being that on try I think perhaps we want more control over which builds are being tested against.
|
||
Comment 1•5 years ago
|
||
how do we find the most recent build on autoland? Is this just iterating through pushes looking for a build? What if a build is in progress? Not sure how simple or complex this bug should be.
|
||
Comment 2•5 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #0)
The scheduling logic should determine that only tests are being changed, and then optimize out build tasks, referencing the most recent non-test-only builds.
How does the scheduling logic know that only test-relevant files are being changed?
|
Reporter | |
Comment 3•5 years ago
|
||
(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #1)
how do we find the most recent build on autoland? Is this just iterating through pushes looking for a build? What if a build is in progress? Not sure how simple or complex this bug should be.
If the build is in progress, we should still depend on it. There should be no reason to trigger a new build.
(In reply to Nathan Froyd [:froydnj] from comment #2)
(In reply to Chris AtLee [:catlee] from comment #0)
The scheduling logic should determine that only tests are being changed, and then optimize out build tasks, referencing the most recent non-test-only builds.
How does the scheduling logic know that only test-relevant files are being changed?
Would some basic filters like only files with "testing/" or "test/" in their path work?
|
|
||
Comment 4•5 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #3)
(In reply to Nathan Froyd [:froydnj] from comment #2)
(In reply to Chris AtLee [:catlee] from comment #0)
The scheduling logic should determine that only tests are being changed, and then optimize out build tasks, referencing the most recent non-test-only builds.
How does the scheduling logic know that only test-relevant files are being changed?
Would some basic filters like only files with "testing/" or "test/" in their path work?
It would probably be good enough for an MVP, yes.
|
||
Comment 5•5 years ago
|
||
You can use this to be a bit more comprehensive: https://github.com/mozsearch/mozsearch/blob/2e24a308bf66b4c149683bfeb4ceeea3b250009a/router/router.py#L127-L135.
|
||
Comment 6•5 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #3)
(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #1)
how do we find the most recent build on autoland? Is this just iterating through pushes looking for a build? What if a build is in progress? Not sure how simple or complex this bug should be.
If the build is in progress, we should still depend on it. There should be no reason to trigger a new build.
In the current state of treeherder, unfortunately, that would not lead to a great user experience in case the build fails, because all that will be seen is... nothing happening on the push at all. Or even if the build doesn't fail, if it's running, there's no indication on treeherder that things are being waited upon. That's one of the reasons why we don't make pushes on top of toolchain changes depend on the toolchain builds from the push that triggered them first (and there are other reasons, but I think most of the others have been solved now). That's bug 1066272.
|
||
Comment 7•5 years ago
|
||
We could also trigger this behavior on requesting artifact builds, since this has the same effect. I'm not sure prevalent the use of artifact builds are (and it would probably make sense to detect when those should be enabled anyway).
Regarding looking at test and testing, that would behave incorrectly for any compiled tests, I think?
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 8•5 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #5)
You can use this to be a bit more comprehensive: https://github.com/mozsearch/mozsearch/blob/2e24a308bf66b4c149683bfeb4ceeea3b250009a/router/router.py#L127-L135.
Joel mentions that we can probably also ignore **/{mochitest,browser,chrome,xpcshell}.ini
|
|
||
Comment 9•5 years ago
|
||
and testing/**
|
|
||
Comment 10•5 years ago
|
||
(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #9)
and testing/**
That includes testing/mozharness which also impacts builds. (I think at least testing/gtest and testing/mozbase may also impact builds).
|
|
||
Comment 11•5 years ago
|
||
ok, then testing/web-platform/meta/** is the best spot, in fact probably just testing/web-platform/**
|
||
Updated•2 years ago
|
Description
•