Anything in CS can be generalized to its purest, most theoretical forms. The question is how usable is it and how much work does it take to get anything done.
Bazel, for example, is tailored to the needs of reproducible builds and meets its audience where it is at, on the command line. People want fast iteration time and only occasionally need "everything" ran.
Github Actions is tailored for completeness and meets is audience where its at, the PR workflow (generally, a web UI). The web UI is also needed for visualizing the complexity of completeness.
I never find myself reproducing my build in my CI but do find I have a similar shape of needs in my CI but in a different way.
Some things more tailored to CI that wouldn't fit within the design of something like Bazel include
- Tracking differences in coverage, performance, binary bloat, and other "quality" metrics between a target branch and HEAD
See
- https://danstroot.com/2018/10/03/hammer-factories/
- https://web.archive.org/web/20120427101911/http://jacksonfis...
Bazel, for example, is tailored to the needs of reproducible builds and meets its audience where it is at, on the command line. People want fast iteration time and only occasionally need "everything" ran.
Github Actions is tailored for completeness and meets is audience where its at, the PR workflow (generally, a web UI). The web UI is also needed for visualizing the complexity of completeness.
I never find myself reproducing my build in my CI but do find I have a similar shape of needs in my CI but in a different way.
Some things more tailored to CI that wouldn't fit within the design of something like Bazel include
- Tracking differences in coverage, performance, binary bloat, and other "quality" metrics between a target branch and HEAD
- Post relevant CI feedback directly on the PR