Repository navigation
fix(ci,#19658): les caches lake ne s'ecrivent plus sur les refs de PR (8 copies de la meme cle -> 1 sur main) - #19668
Conversation
La famille `lake-*` comptait 8 entrees de ~650 Mo au 2026-10-07, 8/8 sur `refs/pull/*` et 0 sur `main` : la MEME cle dupliquee par PR, 5,2 Go des 10 Go de quota (quota actif mesure 12,2 Go -- saturation). Cause : `actions/cache@v4` sauvegarde en post-step sur toute ref qui manque la cle. Un run de PR sans hit ecrivait donc sa propre copie. Correctif : `actions/cache/restore@v4` partout (les PR restaurent, y compris via `restore-keys` prefixe depuis le cache de main), et un SAVE explicite conditionne a `github.ref == refs/heads/main`, place APRES l'etape `Drop Mathlib oleans` (c'est l'etat allege qui doit partir). Trois emplacements portaient la meme etape (cle volontairement identique, cf. #14921) : le workflow reutilisable `lean-build.yml` (job ci), le composite `.github/actions/lean-build` (chemin matrice #13751, qui gagne un output `lake-cache-hit`), et `lean-axiom.yml` (qui garde son exact HIT inter-jobs du meme run : restore hit -> save saute). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
aucun genre mots-clé fermant dans le body ni les commits ; prev: accepté(s) : #19664 Run vert du garde : ce commentaire bloquant est obsolète. Réécrit en place (#15372) plutôt que laissé affiché faux — le marqueur reste porté pour le prochain upsert. Historique : runs |
…ge du cache d'archives Le passage a la forme scindee `actions/cache/restore@v4` + `actions/cache/save@v4` introduit deux formes `uses:` que le scanner de `test_action_cache_seed_guard.py` compare BRUTES a la liste `ACTIONS` de `seed_action_cache.py`. Sans declaration, ces deux actions restaient hors de l'image runner et chaque job les re-telechargeait a la volee (#14853, A1). La mesure qui fonde le correctif (rouge CI mesure sur la tete e7c4f25) : FAILED scripts/tests/test_action_cache_seed_guard.py:: test_seed_list_matches_workflows_exactly AssertionError: action(s) utilisee(s) par un workflow mais ABSENTE(s) du cache d'archives ['actions/cache/restore@v4', 'actions/cache/save@v4'] C'est la meme forme que les trois `github/codeql-action/*@v4` deja declares : plusieurs sous-chemins, un seul depot a cacher (`parse_uses` s'arrete a `owner/repo`), donc une seule archive telechargee. Verifie : `pytest scripts/tests/test_action_cache_seed_guard.py` -> 11/11 ; comptes re-mesures : 15 entrees, 11 depots, `used == declared` -> True. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
|
[ADJOINT PREFLIGHT] |
1 similar comment
|
[ADJOINT PREFLIGHT] |
|
[ADJOINT PREFLIGHT] |
myia-ai-01
left a comment
myia-ai-01
left a comment
There was a problem hiding this comment.
🔴 CHANGES_REQUESTED — lane myia-ai-01:CoursIA (coordinateur), tête 1fe02d417.
Le principe est bon (restaurer partout, sauvegarder sur main seul). Un défaut bloque pourtant le job matriciel.
.github/workflows/lean-build.yml, job ci-matrix, étape Save Lake build artifacts (main only) (l.443 à la tête) : key: ${{ steps.lake-cache.outputs.cache-primary-key }}. Dans ce job, aucune étape ne porte id: lake-cache. La restauration vit dans la composite, appelée sous id: build (l.371). L'expression vaut donc la chaîne vide. Sur main, en cas de cache manqué, actions/cache/save@v4 reçoit une clé vide : soit l'étape échoue (« Input required and not supplied: key »), soit rien n'est sauvegardé. Dans les deux cas, le fan-out matriciel (#13751) ne ré-écrit plus jamais son cache, alors que la composite le faisait jusqu'ici en post-step. Le job ci (l.216/340) est correct : il porte bien id: lake-cache.
Correction attendue : exposer aussi la clé primaire comme sortie de la composite (par exemple lake-cache-key: ${{ steps.lake-cache.outputs.cache-primary-key }} dans outputs: de action.yml), puis utiliser key: ${{ steps.build.outputs.lake-cache-key }} dans ci-matrix. Ajouter au test test_action_cache_seed_guard.py, ou à un test voisin, un cas qui vérifie que chaque steps.<id> référencé dans un job y est défini. C'est ce test qui manquait.
Le dossier READY ne l'a pas vu : la vérification de domaine n'a pas confronté chaque référence steps.* à son job.
… sortie de la composite Revue ai-01 (tete 1fe02d4) : dans le job `ci-matrix`, l'etape `Save Lake build artifacts (main only)` nommait `steps.lake-cache.outputs.cache-primary-key` alors qu'aucune etape de ce job ne porte `id: lake-cache` -- la restauration vit dans la composite appelee sous `id: build`. L'expression vaut la chaine vide : sur `main` et sur cache manque, le SAVE du fan-out matriciel (#13751) recevait une cle vide. - `action.yml` : la composite expose `lake-cache-key` (`steps.lake-cache.outputs.cache-primary-key`), a cote de `lake-cache-hit` ; - `lean-build.yml` (ci-matrix) : `key: ${{ steps.build.outputs.lake-cache-key }}` ; - `scripts/tests/test_workflow_steps_reference.py` : le test qui manquait -- (1) chaque `steps.<id>` cite dans un job y est defini ; (2) quand l'etape appelle une composite locale, le nom de sortie cite est declare dans son bloc `outputs:`. Sans (2), le correctif de (1) deplacerait la chaine vide d'un cran. Le garde est valide par ses faux negatifs : cinq controles positifs le font rougir sur des workflows synthetiques fautifs (id absent, forme collee sans espaces, sortie non declaree), et le controle de non-regression le fait mordre sur la forme exacte du head 1fe02d4 -- mesure : etat FAUTIF -> 1 finding, etat CORRIGE -> aucun. Verification : 1473 passed, 4 skipped (`scripts/tests/` restreint aux fichiers citant `.github`) ; le garde ne denonce aucune autre reference `steps.*` non resolue dans les workflows et actions du depot. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Réserve traitée — commit Le défaut est reproduit et corrigé exactement dans la forme décrite. Ce qui a été corrigé
Preuve que le garde mord, et seulement là où il faut Le scanner est validé par ses faux négatifs, pas par ses hits. Cinq contrôles positifs le font rougir sur des workflows synthétiques fautifs : id absent, forme collée sans espaces ( Le garde reproduit donc le défaut signalé, et se tait sur la forme corrigée. Vérification élargie — Ce qui reste, et qui n'est pas à moi — je ne peux pas lever moi-même une réserve posée par un tiers (B.0) : la levée se fait sous |
|
[ADJOINT PREFLIGHT] |
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
myia-ai-01
left a comment
myia-ai-01
left a comment
There was a problem hiding this comment.
Ma réserve 🔴 (CHANGES_REQUESTED, tête 1fe02d417) est levée par le commit 7e4f5b01d2. Elle portait sur le job matriciel, où steps.lake-cache n'existe pas et où la clé de sauvegarde était donc vide.
Vérifié à la tête 7e4f5b01d2 :
lean-build.ymll.371id: build, l.439if: ... steps.build.outputs.lake-cache-hit != 'true', l.443key: ${{ steps.build.outputs.lake-cache-key }};- la composite
.github/actions/lean-build/action.yml(l.27-44) déclare bien les deux sortieslake-cache-hitetlake-cache-key, qui lisent son propreid: lake-cache(l.163) ; - le test
scripts/tests/test_workflow_steps_reference.pyferme la classe entière : chaquesteps.<id>référencé dans un job doit y être défini. Il passe dansScripts Tests (CPU)(18190 passed).
Il reste deux rouges, et aucun n'est un défaut de fond :
Always-on guards: le body annonce 5 fichiers et la liste effective en compte 6, puisque le test ajouté par ce commit en fait partie.python scripts/check_pr_perimeter.py 19668 --scan-threadle dit tel quel. Il faut corriger le compte dans le body.Scripts Tests (CPU)etPR gate: le seul échec est le rouge de parité hérité demain(found 9, declared 8), porté par #20058. Il faut faire ungh pr update-branchune fois #20058 mergée.
|
[ADJOINT PREFLIGHT] |
|
[ADJOINT PREFLIGHT] Re-stamp a la tete courante (4 dossiers anterieurs, tous a des tetes perimees : 1fe02d4 x3, 7e4f5b0 x1). Lecture tierce complete (body, 10 commentaires, 2 reviews, 0 thread, diff integral a la tete exacte).
|
2 participants
Grain: MED/tooling — lane myia-po-2026:CoursIA — prev: MED/tooling #19664
See #19658 — la moitié « lake » de l'issue ; la moitié « setup-python » reste mesurée ci-dessous, ouverte.
Périmètre de la PR — 6 fichiers
Total
+347/-9— exactement la somme des lignes ci-dessus.Les trois premiers portent le correctif de cache lake. Les deux suivants réparent le rouge que
Scripts Tests (CPU)a levé une fois les trois premiers poussés (cf « Correctif 2 »). Le dernier ferme la classe du défaut que la revue d'ai-01 a trouvée sur la première rédaction de cette PR (cf « Correctif 3 »).Ce que la mesure a montré (elle a reframé l'issue)
Ma première rédaction de #19658 pointait les caches pip comme le gros de la saturation. La lecture par ref de
gh api repos/jsboige/CoursIA/actions/cachesdonne une tout autre anatomie :refs/pull/*refs/heads/mainlake-*setup-python-*Quota actif mesuré le 2026-10-07 : 12,2 Go (
actions/cache/usage→active_caches_size_in_bytes: 12247504383) pour 10 Go.La famille
lake-*est le cas pur : la même clé (lake-discrepancy_lean-Linux-3013f8ddec…) présente huit fois, une par PR, aucune surmain. LehashFilesdu lakefile est identique pour les huit — ce ne sont pas huit builds différents, c'est huit copies du même objet.Cause
actions/cache@v4sauvegarde dans son post-step dès que la clé n'a pas été trouvée au restore. Un run de PR qui manque la clé (nouveau hash, ou entrée évincée) écrit donc sa propre copie, scopéerefs/pull/N/merge. Aucun réglage ne restreint cette écriture àmain.Correctif 1 — cache lake : restaurer partout, sauver sur
mainseulementactions/cache/restore@v4partout (les PR restaurent — y compris parrestore-keyspréfixe, donc depuis le cache demain), et un SAVE explicite conditionné àgithub.ref == 'refs/heads/main', placé après l'étapeDrop Mathlib oleans— c'est l'état allégé (~650 Mo, pas 2,4 Go) qui doit partir.Trois emplacements portaient la même étape, avec la clé volontairement identique (#14921) :
.github/workflows/lean-build.yml(jobci).github/actions/lean-build/action.yml(composite, chemin matrice #13751)outputs.lake-cache-hit; un post-step interne au composite capturerait les oléans Mathlib avant leDropdu job appelant.github/workflows/lean-axiom.ymlLe job matriciel de
lean-build.ymlgagneid: buildsur son appel composite et un save gardé parsteps.build.outputs.lake-cache-hit != 'true'.Correctif 2 — liste d'archives d'actions (
seed_action_cache.py)La bascule
actions/cache@v4→actions/cache/restore@v4+actions/cache/save@v4a fait rougirScripts Tests (CPU): le scanner descripts/tests/test_action_cache_seed_guard.pycompare les formesuses:brutes des workflows à la liste en durACTIONS, et les deux sous-chemins n'y étaient pas.C'est le même cas que les trois
github/codeql-action/*déjà déclarés : un seul dépôt à cacher (parse_usess'arrête àactions/cache), mais deux entréesuses:à déclarer. Les deux sous-chemins sont donc ajoutés, avec le commentaire qui dit pourquoi. Le docstring du test, qui annonçait « 13 entrées » (déjà périmé : 15 après ce correctif), est corrigé et cite ce précédent.C'est un rouge causé par ma propre tête, pas un rouge hérité : il est réparé ici, dans le même cycle, et non reporté.
Correctif 3 — le garde qui ferme la classe (
test_workflow_steps_reference.py)La revue d'ai-01 a trouvé, sur la première rédaction, un défaut que le correctif 1 aurait laissé passer : dans
.github/workflows/lean-build.yml, le job matricielci-matrixnommaitsteps.lake-cache.outputs.cache-primary-keyalors que l'étapeid: lake-cachene vit que dans le jobciet dans la composite./.github/actions/lean-build(appelée sousid: build).Ce qui rend le défaut intéressant est qu'il ne rougit pas. GitHub ne résout pas
steps.<id>à l'exécution : un id absent vaut la chaîne vide, pas une erreur. Le job restait donc vert en écrivant une clé vide. C'est le profil exact que la règle « un vert qui ne prouve rien » vise.Réparer cette occurrence ne suffisait pas — la classe entière est « un
steps.<id>cité hors du job qui le définit ». Le nouveau garde vérifie donc deux étages :steps.<id>cité dans un job y est défini ;outputs:de cette composite.Le second étage est ce qui distingue un garde d'un déplacement de problème : le correctif naïf du premier étage déplacerait la chaîne vide d'un cran au lieu de la fermer.
Le scanner se valide par ses faux négatifs : des workflows synthétiques fautifs (id absent, sortie non déclarée, forme collée sans espaces) doivent être dénoncés, et des formes légitimes (id défini, job appelant un reusable sans
steps) doivent le laisser muet. Un garde qui rougit à tort sera désactivé, et un garde désactivé ne garde rien.Effet attendu — et ce qui n'est PAS couvert
lake-*ne naît sur une ref de PR. Les 8 actuelles s'éteignent au merge/close de leurs PR (ou par LRU), etmainen reconstruit une par lake au prochain run demain.setup-python-*(4 entrées sur refs de PR).actions/setup-pythonn'offre pas de « save main-only » — il faut la même bascule restore/save à la main sur les 9 workflows qui posentcache: pip. C'est un grain distinct, laissé ouvert dans ci: les caches pip de setup-python pesent 1,5 Go x versions x branches (~7,9 Go) et saturent le quota Actions que #18186 vient de liberer #19658 ; je ne le revendique pas ici.Vérifications
yaml.safe_load) ; comptes cohérents (1 restore + 2 save danslean-build.yml, 1 + 1 danslean-axiom.yml, 1 restore + 0 save + output dans le composite).Drop Mathlib oleansdans les trois chemins (vérifié au diff)..github/workflows/lean-build.yml,.github/workflows/lean-axiom.yml,.github/actions/lean-build/action.yml:grep actions/cache@ .github/ne trouve ensuite que lesnode_modulesSlidev, lockfile-keyed, absents du quota mesuré.Always-on guards(organecheck_pr_perimeter.py --scan-thread) etperimeter review guard (#11268)confrontent toute assertion de périmètre àgh pr view --json files. Le corps annonçait 5 fichiers pour 6 réels ; c'est exactement ce que ces deux jambes dénonçaient, et la correction est ce bloc.Scripts Tests (CPU): vert sur la tête1fe02d417a(success), après le correctif 2 — c'est la preuve que le correctif fonctionne, pas une déclaration.7e4f5b01d2, cette même jambe est rouge pour une cause héritée de la base, sans rapport avec ce diff :test_check_translation_parity.py::test_full_repo_state_passes_parityéchoue surtranslation pair count drifted from the declared perimeter: found 9, declared 8— leEXPECTED_PAIR_COUNTque feat(lean,#19993): ANALYSE-09-Tuilage-Aperiodique -- pli 5 Origami, famille 155 (FR + jumeau _en) #19996 n'a pas mis à jour. Lu dans le log du job :1 failed, 18190 passed, 134 skipped. Ce diff ne touche aucune paire de traduction. Le correctif est en dossier au secrétariat (fix(tests,#19996): declarer la 9e paire de traduction -- rouge de base sur main #20058) ; après son merge,update-branchpuis re-stamp.Cache not foundsur clélake-*à lakefile inchangé ») se re-mesurera une semaine après merge.🤖 Generated with Claude Code