Closed Bug 1505072 Opened 10 months ago Closed 10 months ago

Implement `mach rusttests`

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set

Tracking

(firefox65 fixed)

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: ted, Assigned: cmanchester)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(3 files)

I floated this idea in bug 1497477 but the idea of making rusttests Tier 1 came up today and part of that discussion is that it's kind of a pain to run them locally. We should implement `mach rusttests` to make it easy to run these tests.

For an MVP we could put a simple mach command alongside other test commands here:
https://dxr.mozilla.org/mozilla-central/source/testing/mach_commands.py

We don't currently have a good way to invoke just rust tests though, they get run as part of `make check`. I think maybe we can reuse the machinery chmanchester added in bug 1474028 to make this work, though. We'd need to make the emitter run `RUST_TESTS` through the same logic we use for compile targets right now, but with a non-default target like we do with gtests:
https://dxr.mozilla.org/mozilla-central/rev/c291143e24019097d087f9307e59b49facaf90cb/python/mozbuild/mozbuild/backend/recursivemake.py#796-845

If we plumb that all through then that would give us a `recurse_rusttest` make target in the root Makefile which we could easily invoke from the mach command.
Chris: is this something you could find time for?
Flags: needinfo?(cmanchester)
Tentatively yes. We should be able to make the automation tasks way less wasteful along the way.
Assignee: nobody → cmanchester
Flags: needinfo?(cmanchester)
The rusttests no longer require a special build flag, however we still need
mozconfigs specific to these jobs for 1.) Turning off the clang plugin, which
will not get built during these builds and will cause failures when C/C++
needed by the rust build tries to find it. and 2.) Adding --output-sync=line
to our make invocation: at some point the "export" phase started relying on
this, and it's missing because the non-default build targets invoked by
the rusttests builds don't go through client.mk.
Pushed by cmanchester@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/03e11ea4c03a
Implement rusttests as a non-default sub-graph of the build. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/2920480fd7b7
Allow mozharness build jobs to specify non-default build targets. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/9e381bd1d350
Automation and mozconfig changes to convert rusttests builds to use non-default build target. r=froydnj
The ergonomics around running these aren't ideal still, I kept the --enable-rust-tests flag around so code coverage builds can still use it. Filed bug 1505859 to handle this.
Duplicate of this bug: 1497477
chmanchester: nice work here!
https://hg.mozilla.org/mozilla-central/rev/03e11ea4c03a
https://hg.mozilla.org/mozilla-central/rev/2920480fd7b7
https://hg.mozilla.org/mozilla-central/rev/9e381bd1d350
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
We gain some build boost on Linux:

== Change summary for alert #17440 (as of Thu, 08 Nov 2018 16:39:26 GMT) ==

Improvements:

 65%  build times linux32 debug rusttests taskcluster-c4.4xlarge     566.13 -> 200.04

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=17440
Depends on: 1507827
You need to log in before you can comment on or make changes to this bug.