CI: connectivité serveur-de-cache du runner (reserveCache timeout — cause #2) #234
Labels
No labels
autopilot:pending-human
source:analyste
source:defenseur
source:human
source:medic
status:approved
status:blocked
status:in-progress
status:needs-clarification
status:needs-fix
status:ready
status:review
status:triage
type:bug
type:feature
type:infra
type:refactor
type:schema
type:security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: maximus/Simpl-Resultat#234
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 quereserveCachetimeout (même backend).act_runner(bloccache: { 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).cache.hostsur une IP/host joignable depuis le réseau des conteneurs job ; aligner les réseaux Docker job↔runner).Cache saved(plus dereserveCache timeout) puis, au run suivant, un vraiCache restored.Accès hôte VPS requis (
ssh ubuntu@…). Hors des fichiers workflow. Bloque le bénéfice de #232.Après le merge de #375 (2026-10-03)
La connectivité est réparée côté VPS (diagnostic et correctif dans #374), et rust-cache est en place sur
maindepuis #375 (f821492). Le corps de cette issue est dépassé sur la cause : fixercache.hostn'aurait pas suffi, car le port du cache était filtré par ufw et tiré au hasard par le runner.Point 1 de la liste post-merge : fait.
check-rustlancé surmainparworkflow_dispatch(run 464). Il calcule la même clé que l'entrée de la PR (v0-rust-rust-Linux-x64-6448e498-86c598be) et répond pourtantNo cache found.: l'entrée de la PR était bien isolée. PuisCache Size: ~999 MBetCache saved successfully, cette fois dans le cache partagé. Le déclencheurworkflow_dispatchest donc prouvé.Reste avant fermeture, d'où
status:blocked:Restored from cache key … full match: true).Cache up-to-date.ouCache saved successfullydans le journal, puisqu'une sauvegarde ratée laisse le job vert./home/ubuntu/.cache/actcachesur le VPS (Max :du -sh /home/ubuntu/.cache/actcache).L'issue sera fermée à la main avec ces preuves. Suites hors périmètre : #376.
Point 4, premier relevé (Max, 2026-10-03 au soir) :
du -sh /home/ubuntu/.cache/actcachedonne 2,0 Go.C'est le total attendu à ce stade : deux entrées de 999 Mo sous la même clé, celle de la PR #375 (run 459, isolée) et celle du cache partagé (run 464). Le ménage du runner ne garde que la plus récente par clé, mais il ne passe qu'à l'occasion d'une requête au cache, au plus une fois par heure, et la dernière requête date du run 464. Le total doit donc redescendre vers 1 Go au prochain passage, au plus tard avec le run planifié du lundi 2026-10-05.
À relever de nouveau après ce run, avec les points 2 et 3, avant de fermer l'issue.
Point 2 de la liste post-merge : fait (2026-10-04). Premier run
check-rustd'une PR Rust depuis le merge de #375 : la PR #386 (#373), run 480 sur0b94ccf.L'entrée partagée écrite par le
workflow_dispatchsurmain(run 464) est bien lue par une PR, et le job dure 3 min 15 s. Restent les points 3 (premier run planifié du lundi 2026-10-05 à 06:30 UTC,Cache up-to-date.ouCache saved successfullydans son journal) et 4 (taille deactcacherelevée après ce run, attendue vers 1 Go).Point 3 de la liste post-merge : fait. Premier run planifié de
check-rust, lundi 2026-10-05 à 06:30 UTC : run 488 surmain, vert en 3 min 27 s.La clé n'ayant pas changé, rien n'est réécrit. Les PR Rust #386, #387 et #388 ont toutes restauré cette même entrée (runs 480, 482, 486 et 490).
Reste le point 4 avant la fermeture : relever
du -sh /home/ubuntu/.cache/actcachesur le VPS (attendu vers 1 Go, après le passage du ménage du runner).Point 4 : fait, et #234 est close (2026-10-05). Relevé du dossier de cache du runner, à 23:32 UTC :
Il ne reste qu'une seule entrée. L'entrée isolée de la PR #375 a été évincée par le ménage du runner, qui ne garde qu'une entrée par clé : de 2,0 Go le 2026-10-03, le dossier est passé à 999 Mo. Les PR #386, #387 et #388 n'ont rien réécrit, puisqu'elles ont restauré l'entrée partagée en
full matchpuis fini enCache up-to-date..Les quatre preuves de la liste post-merge :
workflow_dispatchsurmainécrit dans le cache partagé (run 464, commentaire 18971).full match: true(PR #386, run 480, commentaire 19473 ; puis runs 482, 486 et 490).Cache up-to-date.(run 488, 3 min 27 s, commentaire 19667).check-rustpasse de 9 min 37 s à froid à environ 3 min 20 s par job. Le reste est suivi dans #376.