|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
We've long had code in taskgraph that only runs tasks for an allow list of platforms for Servo vendoring changes. Now that we build Servo code into Firefox, this filtering is too aggressive and we're failing to find build bustage on some platforms when Servo code is updated.
Note that the majority of directories in servo/ aren't built. The Right Thing to do would be to filter based on the Cargo.lock file in toolkit/library/rust, which is the canonical indicator of the crates we build. We could also do a dumber manual list of stuff we definitely won't be pulling in anytime soon, or we could just always build.
The Decision task is just a bunch of Python code. It doesn't (yet) do anything related to the build system. If we were to intelligently filter changes through Cargo.lock, what would that look like? I assume it involves some subset of "reinvent Cargo?" We probably want to error on the side of caution. i.e. run jobs if there's any doubt. If doing this check correctly is too difficult, it might be best to remove the filter and take the capacity hit :/
The file looks like this: http://searchfox.org/mozilla-central/source/toolkit/library/rust/Cargo.lock I think we could do something like: If the changes are in servo/components/foo and there is not a line of the form |name = "foo"| in Cargo.lock, they are NPOTB. Worth running that by somebody else, but it seems like it would work.
Comment on attachment 8890601 [details] Bug 1384759 - Only filter test tasks for Servo changes; https://reviewboard.mozilla.org/r/161762/#review167420 I could have sworn that there are tests related to this filter, and tweaking the filter would thereby break those tests, but I cannot find them right now. I think bholley is right that we could be smarter, but we can at least land this change to start catching build bustage. We can then make things smarter if we find we're building too much (who wants to write the Cargo.lock analysis for the last three months or so?). My impression is that the commit volume for Servo is both low enough to not be worried about it, and the majority of commits right now touch code that we would care about anyway, so smarter filtering wouldn't buy that much.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/13358d0eb5a1 Only filter test tasks for Servo changes; r=froydnj