-
Notifications
You must be signed in to change notification settings - Fork 647
CI: Build backend tests in /mnt
#9051
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9051 +/- ##
==========================================
- Coverage 89.05% 89.04% -0.01%
==========================================
Files 278 278
Lines 27987 27987
==========================================
- Hits 24923 24922 -1
- Misses 3064 3065 +1 ☔ View full report in Codecov by Sentry. |
GitHub's ubuntu-22.04 runner only guarantees 14 GB of free space on /, which turns out to not quite be enough any more for our backend tests to be built and run. GitHub runners also provide a larger temporary partition on /mnt, so let's use that for our target directory. This appears to be very slightly slower (~10% slowdown) than building and running on /, but since it works and / doesn't, here we are. Note that the presence of /mnt isn't really guaranteed by the GitHub documentation. It was apparently previously suggested by the Azure docs[^azure], but the current version doesn't include any reference to /mnt that I can see. I don't think there's a lot of downside in us making this change right now. It feels fragile, but our other option would pretty much be to use something like the `maximize-build-space` action[^action] to take out the parts of the ubuntu-22.04 image that we don't need, which is just as implementation specific. Or we could run tests for each workspace member in turn, but then we'd have to clean up and would probably lose all the benefits of the caching we have in CI right now. Fixes rust-lang#9050. [^action]: https://github.com/easimon/maximize-build-space [^azure]: https://learn.microsoft.com/en-us/previous-versions/azure/jj672979(v=azure.100)?redirectedfrom=MSDN
.github/workflows/ci.yml
Outdated
- run: cargo build --tests --workspace --target-dir=/mnt/target | ||
- run: cargo test --workspace --target-dir=/mnt/target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you think about setting CARGO_TARGET_DIR
instead of using CLI args?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've switched it over to using the env var. Also cut down on the duplication a little bit :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's almost certainly better. Thanks.
/mnt
GitHub's ubuntu-22.04 runner only guarantees 14 GB of free space on /, which turns out to not quite be enough any more for our backend tests to be built and run. GitHub runners also provide a larger temporary partition on /mnt, so let's use that for our target directory.
This appears to be very slightly slower (~10% slowdown) than building and running on /, but since it works and / doesn't, here we are.
Note that the presence of /mnt isn't really guaranteed by the GitHub documentation. It was apparently previously suggested by the Azure docs1, but the current version doesn't include any reference to /mnt that I can see.
I don't think there's a lot of downside in us making this change right now. It feels fragile, but our other option would pretty much be to use something like the
maximize-build-space
action2 to take out the parts of the ubuntu-22.04 image that we don't need, which is just as implementation specific. Or we could run tests for each workspace member in turn, but then we'd have to clean up and would probably lose all the benefits of the caching we have in CI right now.Fixes #9050.
Footnotes
https://learn.microsoft.com/en-us/previous-versions/azure/jj672979(v=azure.100)?redirectedfrom=MSDN ↩
https://github.com/easimon/maximize-build-space ↩