WARNING: Github runner disk layout is now a fast moving target, breaking this action for many

[easimon]

Since the initial release I considered this action an ugly hack, to be used as a last resort only, because it depended on an undocumented "feature" of Github runners: an unused disk attached to the VM.

Over the last months, Github seems to regulary change the runner disk layout. The pattern is unclear for me. There seem to be differences between "free" runners and those used in Github Enterprise, but this does not seem to be everything.

Some runners now have both larger / and a larger /mnt, resulting in an enormous amount of total space, others have only 15GB free on / and seem to completely miss the temporary disk mounted on /mnt, so there's nothing to add space from.

Finding all these bits and pieces to make this work back when I created the action was quite fiddly -- but at least all "default" runners looked the same, so it was constant for everyone. Now, given this very mixed experience, I doubt that it makes sense to keep the action alive "as is" -- if at all.

Input on this is welcome, until then, this issue should serve as an additional warning to those considering the use of this action.

[mirage335]

Please do continue maintaining this action. For builds which absolutely must have at minimum two simultaneous copies of a large file, or builds which do an analysis/diff of a package compared to previous builds, more disk space is essential.

In particular, it is very useful to run scheduled builds on the free runners. Many bugs are caught that otherwise would not be caught.

An extreme solution would be to use an LLM in the action to make reasoned decisions. While that may not seem reliable or feasible, in fact, I have had no trouble running 'ollama' with an 'augment' model of Llama 3.1 within GitHub Actions runners, and adding reasoning to shell scripts reliably with that. The bash shellcode to fetch that model is at https://github.com/mirage335-colossus/ubiquitous_bash/blob/ae067b11fd1bcaf1e72fd34dcd33a049caebbda1/ai/ollama/ollama.sh#L117 .

Another hint: seems runners for private runners are different, while public repository runners so far have remained unchanged for a long time for me.

[jianlins]

For some cases, /mnt is large enough for my use. Is there a way to mount that only, I guess it might avoid some of the errors?

[aep-sunlife]

Given stability concerns, this would be good to mention at the top of the readme as a warning.

Recommend avoiding making changes to volatile, low level components.

In fact, this volatility is good fodder to submit to the GitHub vendor. They shouldn't be refactoring so rapidly, nor bloating runners, in the first place. They should also provide convenient, stable scripts to automate removing extraneous components.