CI: connectivité serveur-de-cache du runner (reserveCache timeout — cause #2) #234

New issue

Open

opened 2026-07-01 00:45:49 +00:00 by maximus · 0 comments

maximus commented

2026-07-01 00:45:49 +00:00

Owner

Refs: spec-decisions-ci-build-optimization.md + spec-plan-ci-build-optimization.md ; baseline #231.

La baseline (#231) confirme la cause #2 : le save du cache Actions échoue systématiquement avec reserveCache failed: Request timeout → aucun cache persisté → recompilation complète (~24 min) à chaque run, + ~7 min/run gaspillées en tentatives de save. Le conteneur job n'atteint pas de façon fiable le serveur de cache d'act_runner (gotcha réseau documenté Gitea).

C'est le vrai blocage : ni le cache manuel actuel ni Swatinem/rust-cache (#232) ne peuvent aider tant que reserveCache timeout (même backend).

Sur le VPS/hôte runner : inspecter la config act_runner (bloc cache: { enabled, dir, host, port }) et vérifier que le conteneur job (réseau Docker) atteint bien le serveur de cache du runner (host/port joignables).
Corriger la connectivité (ex : fixer cache.host sur une IP/host joignable depuis le réseau des conteneurs job ; aligner les réseaux Docker job↔runner).
Re-lancer une PR de contrôle : confirmer Cache saved (plus de reserveCache timeout) puis, au run suivant, un vrai Cache restored.
Une fois la connectivité OK : #232 (rust-cache) prend son sens (cache réellement persisté + pruné).

Accès hôte VPS requis (ssh ubuntu@…). Hors des fichiers workflow. Bloque le bénéfice de #232.

Refs: spec-decisions-ci-build-optimization.md + spec-plan-ci-build-optimization.md ; baseline #231. La baseline (#231) confirme la **cause #2** : le save du cache Actions échoue systématiquement avec `reserveCache failed: Request timeout` → aucun cache persisté → recompilation complète (~24 min) à chaque run, + ~7 min/run gaspillées en tentatives de save. Le conteneur job n'atteint pas de façon fiable le serveur de cache d'`act_runner` (gotcha réseau documenté Gitea). C'est le **vrai blocage** : ni le cache manuel actuel ni `Swatinem/rust-cache` (#232) ne peuvent aider tant que `reserveCache` timeout (même backend). - [ ] Sur le VPS/hôte runner : inspecter la config `act_runner` (bloc `cache: { enabled, dir, host, port }`) et vérifier que le conteneur job (réseau Docker) atteint bien le serveur de cache du runner (host/port joignables). - [ ] Corriger la connectivité (ex : fixer `cache.host` sur une IP/host joignable depuis le réseau des conteneurs job ; aligner les réseaux Docker job↔runner). - [ ] Re-lancer une PR de contrôle : confirmer `Cache saved` (plus de `reserveCache timeout`) puis, au run suivant, un vrai `Cache restored`. - [ ] Une fois la connectivité OK : #232 (rust-cache) prend son sens (cache réellement persisté + pruné). Accès hôte VPS requis (`ssh ubuntu@…`). Hors des fichiers workflow. Bloque le bénéfice de #232.