Doctests running on Github Actions running out of disk space, any suggestions?

[KSwanson]

I have a repo I'm helping to maintain which is up on Github, and I've been having a problem where running cargo test fails because the Runner runs out of disk space (specifically, we get linking with cc failed and /usr/bin/ld: final link failed: No space left on device errors). This always happens during the point where cargo test reaches the doctests.

My understanding is that Cargo compiles each doctest as its own separate binary, which explains why this would happen. So far, all I have tried is specifying --jobs 1 to cargo test, since my understanding is that the doctest binary is deleted after it is run; but we are still seeing this fail.

My next two thoughts as to how to solve my problem are:

1. Run the tests in --release mode--I was avoiding this because my understanding is that it would be slower, and it wasn't clear to me that it would use less disk space while building; but I don't mind the increase in time if it makes the tests reliable
2. Do some of the stuff listed here, such as removing .Net and Haskell...I'm loath to depend on something not really supported by GitHub though

Anyway, I guess my main questsion are:

1. Will running doctests with --release save me any disk space usage during builds?
2. Does anyone have any experience or tips with running doctests on Github Runners?

[kpreid]

matklad's article on Fast Rust Builds incidentally contains some suggestions for reducing the disk size:

Disable incremental compilation. CI builds often are closer to from-scratch builds, as changes are typically much bigger than from a local edit-compile cycle. For from-scratch builds, incremental adds an extra dependency-tracking overhead. It also significantly increases the amount of IO and the size of ./target, which make caching less effective.

Disable debuginfo — it makes ./target much bigger, which again harms caching. Depending on your preferred workflow, you might consider disabling debuginfo unconditionally, this brings some benefits for local builds as well.

...

Another obvious advice is to use fewer, smaller dependencies.