Well, it’s the same as regular GHA runners.
On GitHub provided runners you need to explicitly move data between jobs.
I find that useful in preventing weird side effects in one job affecting another.
If the data is also encrypted at rest (as they claim it is), then even if the raw data is recovered it shouldn't be useable without a combination of key leak.
Although we have a KEK and DEK code for regular VMs, they are not operative on GHA...yet. The reason has to do with a technical conflict with copy-on-write we aim to close, not least of which because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today.
I expect within a few months, all expired GHA vms will be cryptoshredded upon their deletion. This is already true for regular virtual machines or managed postgres machines.
The GitHub image is 86GB and people want an action VM to start reasonably quickly, so a full copy for every run isn’t going to work so well.
As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work.
> As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work.
As someone who has authored a GitHub Action to delete like 85% of the hodge-podge stuff blasted all over in a default runner image to free up more space for a Nix store. It's "nuts" indeed.