May 2023 Summaries

Docker image builds use layer caching to avoid rerunning commands whose filesystem changes have already been saved, while most CI systems rely on ephemeral virtual machines and manual, key-based archive caches that require each step to define restoration and storage logic. The same layer-based approach can be adapted for VM-based CI builds through OverlayFS, Docker’s recommended union filesystem, by creating a filesystem layer for each command, archiving its changes, and restoring a matching layer instead of re-executing the command. Although cache validity must account for factors such as environment variables and non-filesystem side effects, this technique can bring Docker-like caching to VM workflows, which may be preferred by engineers seeking a more familiar and less constrained build environment. RWX states that it is implementing this capability in its CI/CD platform.

GitHub Actions workflows can face software supply-chain risks because many third-party actions are referenced through mutable tags such as `actions/checkout@v3`, allowing upstream changes, including malicious or breaking ones, to affect future builds automatically. Although actions can be pinned to an immutable commit hash, GitHub Actions lacks a built-in mechanism for easily updating those locked dependencies, creating a tradeoff between protection from unexpected upstream changes and exposure to outdated actions missing security fixes. The proposed solution is syntax that combines a human-readable mutable version reference with a fixed commit revision, enabling workflows to remain reproducible while supporting straightforward dependency updates. The author notes that RWX, a CI/CD platform under development, intends to avoid this design issue.