CI: use alternative disks if available

[the8472]

cleaning up disk space takes a lot of time, sometimes 30 minutes

[rustbot]

r? @marcoieni

rustbot has assigned @marcoieni.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[the8472]

OLD https://github.com/rust-lang/rust/actions/runs/18821126435
NEW https://github.com/rust-lang/rust/actions/runs/18821542169

[marcoieni]

can you add more comments explaining what you are doing here? 🙏

[marcoieni]

I have no objections if this works as it seems faster than freeing up disk space 🙌
Let's make sure to try this on many jobs to prevent the auto build to fail.
I would definitely mark this as rollup never.

[the8472]

added an exit 1 here

[marcoieni]

sorry if I took so long reviewing this.

So if the mount fails, CI fails? Shouldn't we fallback to disk space cleanup?

[the8472]

hrrm maybe. Something going wrong here is kind of unexpected. It means the mountpoint does exist but the mount options are wrong, e.g. because it's not ext4.
I suppose microsoft could change their default filesystem choice for some reason...

I guess I'll just print a warning and then fallback.

[the8472]

changed it to warning + fallback

[the8472]

I was also thinking: it's possible to run this github action step in the background, right?
We would wait for it before the docker build start.

Kinda, but deleting currently takes many more minutes than it takes us to reach the docker step, so it doesn't save that much.
I tried running both directory enumeration and deleting in parallel fashion and it looked like it maybe it cut down times, but the variance from run to run is so high that I'm not sure.

We could even run it in parallel with the docker step too since docker doesn't need the space immediately, but that would risk failures when deleting is really slow, like the 30 minutes I linked at the top.

So switching to a different drive is much faster, as long as it is available.

[marcoieni]

@bors try jobs=dist-x86_64-linux,x86_64-gnu-aux,dist-aarch64-linux,aarch64-gnu-llvm-20-1

[rust-bors]

💔 Test for 5c6810b failed: CI. Failed jobs:

• try - dist-x86_64-linux (web logs, extended logs)

[marcoieni]

sorry if it took me a lot of time to get back on this. Apparently there are some issues.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[the8472]

@bors try jobs=dist-x86_64-linux

[rust-bors]

💔 Test for a9b4cb9 failed: CI. Failed jobs:

• try - dist-x86_64-linux (web logs, extended logs)

[the8472]

Ah the codebuild runners are running inside a container, I assumed it would be the host. Doing filesystem shenanigans inside a container isn't a good idea.
Then I'll remove that section. Those boxes have enough disk space anyway, we can just skip cleanup.

[the8472]

Then I'll remove that section.

... but it did work on the aarch64 runners, so we need it after all.

[marcoieni]

@bors try jobs=dist-x86_64-linux,x86_64-gnu-aux,dist-aarch64-linux,aarch64-gnu-llvm-20-1

[rust-bors]

💔 Test for bf5291a failed: CI. Failed jobs:

• try - x86_64-gnu-aux (web logs, extended logs)

[rust-log-analyzer]

The job x86_64-gnu-aux failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

/dev/sda1        74G  4.1G   66G   6% /mnt
tmpfs           1.6G   12K  1.6G   1% /run/user/1001
================================================================================

/mnt is a mountpoint
Sufficient space available on /dev/sda1 mounted at /mnt
##[group]Run src/ci/scripts/setup-environment.sh
src/ci/scripts/setup-environment.sh
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}