Some build steps can be cached.
Some preconfiguration of the host machine can be stored in a container image. (If I recall correctly, the GH Actions runner itself is a container: preinstalling packages on occasion, and saving the container image, can greatly speed up iteration on individual PRs).
Prerequisite for such caching of build results is to split things up into phases that can be run from the main script via an argument.
The phases need to be at minimum:
- machine configuration (so we can archive the builder environment at that point: install of clang, cairo, ...)
- artifact-cachable phases (so we don't necessarily start from scratch -- but only if we can guarantee reproducibility)
Then CI can invoke these as multiple steps, and on end-user machines, the script can default to running all phases in order.
Some build steps can be cached.
Some preconfiguration of the host machine can be stored in a container image. (If I recall correctly, the GH Actions runner itself is a container: preinstalling packages on occasion, and saving the container image, can greatly speed up iteration on individual PRs).
Prerequisite for such caching of build results is to split things up into phases that can be run from the main script via an argument.
The phases need to be at minimum:
Then CI can invoke these as multiple steps, and on end-user machines, the script can default to running all phases in order.