Stop cross-building cargo test binaries for macOS
Categories
(Core :: Graphics: WebRender, enhancement)
Tracking
()
People
(Reporter: kats, Assigned: kats)
References
Details
(Whiteboard: [gfx-noted])
Attachments
(1 file)
In bug 1516568 when I added mac CI for webrender on treeherder, I had to cross-compile the cargo test binaries from linux to mac, and then run them on mac. I did this because running cargo test directly on mac produced strange errors (one stack overflow when compiling gleam, and unused variable warnings). Looks like these issues have all been resolved now as of rustc 1.33, and so we can stop doing the cross-compiling business for cargo test and just run it directly on macOS.
This has a few advantanges. The main one is that the configuration is simpler and closer to what a dev would actually do locally to run the tests. Also in terms of job scheduling we don't need a linux host as well as a mac host.
Note that the "release" macOS job (which builds headless wrench) is still being cross-compiled; this bug is just about the "debug" macOS job which is much simpler and can easily be run directly on macOS.
|
Assignee | |
Comment 1•5 years ago
|
||
This works now as of rustc 1.33, and makes things simpler.
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
An advantage to cross-compiling is that mac hosts are quite a bit more expensive.
|
|
Assignee | |
Comment 3•5 years ago
|
||
True. Looking at the jobs this goes from 23 minutes of macOS time to 38 minutes of macOS time per push that touches gfx/wr. So maybe a couple of hours of macOS time per day? I don't know if that's enough to worth worrying about.
|
|
Assignee | |
Comment 4•5 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
True. Looking at the jobs this goes from 23 minutes of macOS time to 38 minutes of macOS time per push that touches gfx/wr. So maybe a couple of hours of macOS time per day? I don't know if that's enough to worth worrying about.
Looks like something landed recently that enabled some sort of caching of the m-c checkout on the macOS workers, so now on m-c the macOS cargotest job runtime is ~3-4 minutes (after a ~12 minute cross-compile time on a Linux worker). With this patch those two jobs get combined into a ~20 minute macOS job. So I guess even not accounting for the extra money cost the total latency is worse with the change, assuming a Linux worker is available within < 5 minutes (which is usually the case).
Closing as wontfix for now but we can always resurrect the patch if things change.
Description
•