mirror of
https://github.com/pi-hole/FTL.git
synced 2026-08-21 05:27:33 +01:00
DL6ER
4215370c52
CI starts from a fresh checkout on a fresh runner every time, so cmake has no build tree to compare against and recompiles all 207 translation units on every run. That is the bulk of every build job, and on `linux/riscv64`, which runs under QEMU, a single unit - `src/database/sqlite3.c` - dominates it. `ccache` is keyed on content rather than on mtimes in a build tree, so it survives the fresh clone. The workflow restores it into the build context before the build, where `.github/Dockerfile` picks it up through its `COPY`, and exports it again afterwards for the next run. Entries are keyed per matrix entry, since the platforms compile for different architectures and the clang job uses a different compiler. Measured locally on `linux/amd64` by building `.github/Dockerfile` twice: ``` unchanged tree 207 / 207 hits 55.2s -> 6.2s one .c file edited 206 / 207 hits src/FTL.h edited 104 / 207 hits ``` The last row is the point: editing our central header correctly recompiles every unit that includes it, while the vendored units that do not - sqlite3, dnsmasq, lua, tre-regex, civetweb - stay cached. `ccache` records which headers each unit pulled in, so it cannot serve a stale object for a changed input, only skip work that would have produced an identical one. `ccache` is installed in `.github/Dockerfile` rather than in the ftl-build image so this can be measured without cutting a new base image release first. Once the payoff is confirmed on CI it belongs in ftl-build, and this `apk add` goes away. The saved cache is about 30 MB per matrix entry per run. Signed-off-by: DL6ER <dl6er@dl6er.de>