#182 a ajouté les secrets sccache au workflow réutilisable, et FerrFleet-Cloud#508 a instrumenté le premier Dockerfile.
Pourquoi ce n'est pas encore déployé
Le premier build après merge donne :
sccache active
Compile requests 598
Cache hits 0 (0.00 %)
Cache misses 510
Cache write errors 0
sccache active prouve la prémisse réseau — garage est joignable depuis l'intérieur du build, grâce à --isolation=chroot qui fait partager le réseau du pod aux RUN. Et 0 write errors sur 510 misses veut dire que le cache s'est rempli.
Mais 0 hit : ce build n'a rien gagné (~18 min, comme avant). C'est le comportement attendu d'un cache froid. La preuve est au build suivant. Si le taux reste à 0, les clés ne se rejouent pas d'un build à l'autre et il faut creuser avant d'élargir.
À faire une fois le taux de hits non nul confirmé
Même changement dans les quatre autres images Rust :
FerrLabs/FerrLabs-Cloud — api/DockerfileFerrLabs/FerrVault-Cloud — api/DockerfileFerrLabs/FerrTrack-Cloud — api/DockerfileFerrLabs/FerrGrowth-Cloud — api/Dockerfile
Plus FerrFleet-Cloud/api/runner/Dockerfile, laissé hors du pilote : les secrets lui sont déjà passés, mais il ne les monte pas, donc il les ignore silencieusement.
Chaque dépôt a besoin de : le bump du SHA épinglé de reusable-docker-build.yml, les deux secrets passés dans son docker.yml, et l'instrumentation du Dockerfile (installation de sccache + montage des secrets + RUSTC_WRAPPER conditionnel).
Le problème d'origine, pour mémoire
Le commit de release bump la ligne version de api/Cargo.toml, entrée de la couche qui met en cache la compilation des dépendances. Une couche invalidée invalide ses descendantes → ~10 min à recompiler des crates qui n'ont pas changé. Cargo.lock, lui, n'est pas touché : le seul fichier qui casse le cache est celui dont la modification ne change rien à ce qui doit être compilé.
Mesuré sur FerrFleet : 15 à 21 min par image.
#182 a ajouté les secrets sccache au workflow réutilisable, et FerrFleet-Cloud#508 a instrumenté le premier Dockerfile.
Pourquoi ce n'est pas encore déployé
Le premier build après merge donne :
sccache activeprouve la prémisse réseau — garage est joignable depuis l'intérieur du build, grâce à--isolation=chrootqui fait partager le réseau du pod auxRUN. Et0 write errorssur 510 misses veut dire que le cache s'est rempli.Mais 0 hit : ce build n'a rien gagné (~18 min, comme avant). C'est le comportement attendu d'un cache froid. La preuve est au build suivant. Si le taux reste à 0, les clés ne se rejouent pas d'un build à l'autre et il faut creuser avant d'élargir.
À faire une fois le taux de hits non nul confirmé
Même changement dans les quatre autres images Rust :
FerrLabs/FerrLabs-Cloud—api/DockerfileFerrLabs/FerrVault-Cloud—api/DockerfileFerrLabs/FerrTrack-Cloud—api/DockerfileFerrLabs/FerrGrowth-Cloud—api/DockerfilePlus
FerrFleet-Cloud/api/runner/Dockerfile, laissé hors du pilote : les secrets lui sont déjà passés, mais il ne les monte pas, donc il les ignore silencieusement.Chaque dépôt a besoin de : le bump du SHA épinglé de
reusable-docker-build.yml, les deux secrets passés dans sondocker.yml, et l'instrumentation du Dockerfile (installation de sccache + montage des secrets +RUSTC_WRAPPERconditionnel).Le problème d'origine, pour mémoire
Le commit de release bump la ligne
versiondeapi/Cargo.toml, entrée de la couche qui met en cache la compilation des dépendances. Une couche invalidée invalide ses descendantes → ~10 min à recompiler des crates qui n'ont pas changé.Cargo.lock, lui, n'est pas touché : le seul fichier qui casse le cache est celui dont la modification ne change rien à ce qui doit être compilé.Mesuré sur FerrFleet : 15 à 21 min par image.