Skip to content

ci(lean): les caches .lake de 2,4 Go embarquent les oléans Mathlib déjà servis par lake exe cache get — trois lakes remplissent le quota #18185

Description

@jsboige

Constat (mesuré le 2026-09-28 vers 07:15Z, après le merge de #18183)

Quota Actions du dépôt : 9,28 Go sur 10 Go, 18 caches. La place est prise par trois caches lake-* :

Clé Taille Création
lake-knot_lean-Linux-821f5e3b… 2 475 Mo 28/09 07:00Z
lake-game_theory_lean-Linux-494890ee… 2 426 Mo 28/09 05:13Z
lake-assignment_lean-Linux-585089ea… 2 412 Mo 28/09 05:14Z

Ces trois caches pèsent 7,3 Go à eux seuls. Les bases CodeQL overlay, bornées par #18183 à trois par famille, n'en pèsent plus que 1,1 Go.

Quinze workflows appellent lean-build.yml. Au rythme de 2,4 Go par lake, trois lakes suffisent à remplir le quota : le cache d'un quatrième lake évince, par ancienneté, celui qui a tourné le moins récemment. C'est la cause de fond des builds à froid de knot_lean sur #18100 (Cache not found, puis mort de la VM hébergée). Le nettoyage des overlays (#16088, #18183) a supprimé un facteur aggravant, mais pas cette cause.

Pourquoi un cache pèse 2,4 Go

lean-build.yml:210-214 met en cache tout ${project}/.lake, y compris .lake/packages/*/.lake/build, c'est-à-dire les oléans compilés de Mathlib et de ses dépendances. Or l'étape Lake build lance déjà lake exe cache get (ligne 270), qui télécharge ces mêmes oléans depuis le serveur de cache de Mathlib, hors quota.

Mesure locale sur knot_lean : .lake/build, c'est-à-dire les modules propres au projet, pèse 28 Mo ; .lake/packages pèse 739 Mo en local, et plusieurs Go en CI une fois les oléans de Mathlib décompressés.

Proposition

Exclure les oléans des paquets du chemin mis en cache, et garder les sources clonées et le build local :

path: |
  ${{ inputs.project-path }}/.lake
  !${{ inputs.project-path }}/.lake/packages/*/.lake/build

Effet attendu : chaque cache lake descend à quelques centaines de Mo, ce qui permet de loger les quinze lakes dans le quota. Les oléans de Mathlib reviennent par lake exe cache get à chaque run, avec un coût de l'ordre de la minute à mesurer.

Risque à trancher avant la PR

  1. Panne du serveur de cache de Mathlib. lake exe cache get || true avale l'échec, et le run recompile alors Mathlib depuis les sources, ce qui prend des heures. Aujourd'hui, un cache Actions restauré protège de ce cas ; avec la proposition, cette protection disparaît. Une parade possible : faire échouer le run sur cet échec plutôt que de recompiler.
  2. Dépendances hors Mathlib. Un lake dont une dépendance n'est pas servie par le cache de Mathlib recompilerait cette dépendance à chaque run. Il faut recenser les lakefile avant de changer le chemin.

Critères de sortie

  • La somme des caches lake-* se mesure sous un plafond qui laisse la place aux quinze lakes. Mesure : gh api repos/jsboige/CoursIA/actions/caches.
  • Plus de Cache not found sur une clé lake-* dont le lakefile n'a pas changé, sur une semaine de runs.
  • Le temps d'une jambe Lean avec cache chaud ne se dégrade pas de plus d'une minute. Mesure : avant et après, sur knot_lean et conway_lean.

Voir #16088 (overlays CodeQL), #18183 (organe d'éviction), #18100 (instance).

Lane : myia-ai-01:CoursIA (CI).

Activity

  1. jsboige commented on Sep 28, 2026

    @jsboige
    OwnerAuthor

    [CLAIMED] lane myia-ai-01:CoursIA -- PR #18186 (retrait des oléans Mathlib avant la sauvegarde du cache ; chemin et clé inchangés)

  2. added a commit that references this issue on Sep 28, 2026
  3. added
    candidate-deliveredReferenced by a merged PR with no post-merge activity -- candidate for close triage (#10466)
    and removed
    candidate-deliveredReferenced by a merged PR with no post-merge activity -- candidate for close triage (#10466)
    on Sep 29, 2026
  4. jsboige commented on Oct 3, 2026

    @jsboige
    OwnerAuthor

    [CLAIMED] lane myia-po-2023:CoursIA -- verification des 3 criteres de sortie apres merge de la PR #18186 (mesure : somme caches lake-* via API, Cache not found sur 5 j de runs, temps de jambe avant/apres) -- livrable = commentaire de mesure. Aucune edition de fichier.

    Grain: MED/lean — lane myia-po-2023:CoursIA — prev: MED/notebook-python #18999

  5. jsboige commented on Oct 3, 2026

    @jsboige
    OwnerAuthor

    Mesure des critères de sortie — 5 jours après le merge de #18186 (lane myia-po-2023:CoursIA, 03/10 19:4xZ)

    Méthode : API actions/caches (35 entrées, paginé) + durées des jobs Lean CI avant/après le 28/09 16:24Z + lecture des logs des jobs knot_lean (annulée, 9 269 s) et conway_lean (verte). Toutes les mesures ci-dessous sont directes.

    Critère 1 — somme des caches lake-* : VERT

    • 9 caches lake-* coexistent (hecke, galois, planning, formal_groups, sensitivity, percolation, grothendieck, social_choice_peters, knot absent — voir critère 2) pour 5 154 Mo au total, moyenne ~573 Mo.
    • Avant fix(ci,#18185): drop Mathlib oleans before the Lean cache save #18186 : 3 lakes = 7,3 Go remplissaient le quota à eux seuls ; unitairement 2 412-2 475 Mo → désormais 638-649 Mo (÷3,8). Le plafond demandé (« laisser la place aux quinze lakes ») est atteint dans les faits : 9 cohabitent sans s'évincer.
    • Fait nouveau hors scope : les 3 caches setup-python pèsent 4 626 Mo (3 × 1 542 Mo) et deviennent le premier consommateur du quota — 2 variantes de la même clé Python 3.12 ont été écrites à 90 s d'écart aujourd'hui. Piste de suivi distincte si le quota redevient tendu.

    Critère 3 — temps de jambe, cache chaud pas dégradé > 1 min : VERT (conway_lean)

    Période Runs conway_lean Durées
    Avant (28/09, cache chaud ancien format) main 27/09 + branches 28/09 matin 2 605 · 2 648 · 2 650 · 2 724 s
    Après (03/10, cache froid, oléans serveur Mathlib) main ×2 + branches ×2 1 096 · 1 394 · 1 600 · 2 228 s

    Pas de dégradation : même les runs conway à froid (clé neuve, oléans re-téléchargés) sont plus rapides que les runs chauds d'avant. knot_lean n'est pas mesurable à chaud (aucun run chaud depuis le merge — voir ci-dessous).

    Critère 2 — plus de Cache not found à lakefile inchangé : ROUGE transitoire (transition), attendu de se refermer

    Verdict

    Critère État
    1. Place pour les lakes dans le quota VERT (9 lakes, ÷3,8 unitaire)
    2. Plus de Cache not found à lakefile inchangé Transitoire — occurrence knot 03/10, se referme au premier run knot abouti
    3. Jambe pas dégradée > 1 min VERT (conway : froid après < chaud avant)

    Recommandation : laisser le run en cours finir ; dès qu'un run knot vert porte Cache saved sur 821f5e3b, re-vérifier le critère 2 sur les runs suivants (balayage ~10 min) — alors vert, et la fermeture devient défendable (décision coordinateur). Point de vigilance durable à tracker séparément si souhaité : le chemin froid knot_lean reste > 2 h 35 sur le module combinatoire ReidemeisterCombinatorial_en — antérieur à #18186, non résolu par lui.

    Reproduire : gh api repos/jsboige/CoursIA/actions/caches --paginate ; logs jobs 111238132904 (knot annulée) et 111220002684 (conway verte).

  6. jsboige commented on Oct 4, 2026

    @jsboige
    OwnerAuthor

    Critère 2 — refermeture mesurée (lane myia-po-2023:CoursIA, 04/10 ~12:5xZ)

    Suite de la mesure du 03/10 : la fenêtre transitoire du critère 2 s'est refermée comme prédit.

    • Run knot vert porteur : 37182430320 (branche main), démarré 06:18:42Z, success à 09:12:55Z. Il porte Cache saved sur la clé lake-knot_lean-Linux-821f5e3b….
    • Clé réécrite en format réduit : présente à l'instant via l'API caches — 707 Mo, créée 09:09:36Z (vs 2 475 Mo en ancien format, ÷3,5 ; prédiction ~650 Mo).
    • Occurrences Cache not found depuis la refermeture : aucune — aucun run knot n'a tourné après 09:12:55Z (0 opportunité). La clé étant présente, le prochain run à lakefile inchangé la trouvera.

    Verdict final des 3 critères

    Critère État
    1. Place pour les lakes dans le quota VERT (mesuré 03/10 : 9 lakes, ÷3,8 unitaire)
    2. Plus de Cache not found à lakefile inchangé VERT — fenêtre refermée 09:09:36Z par le run vert 37182430320, zéro occurrence depuis
    3. Jambe pas dégradée > 1 min VERT (mesuré 03/10 : conway froid après < chaud avant)

    Les trois critères de sortie sont verts. La fermeture de l'issue devient défendable — décision coordinateur (le porteur du claim ai-01 ayant livré #18186). Le périmètre de mon claim (« vérification des 3 critères, livrable = commentaire de mesure, aucune édition de fichier ») est rempli.

    Coût de transition mesuré au passage : le run vert a duré 2 h 54 (rebuild à froid complet, écriture de la clé neuve) — one-shot, antérieur à rien ; les runs suivants trouvent la clé réduite. Le point de vigilance durable du 03/10 reste inchangé et hors périmètre : chemin froid knot_lean > 2 h 35 sur ReidemeisterCombinatorial_en, antérieur à #18186.

    Reproduire : gh api "repos/jsboige/CoursIA/actions/caches?per_page=100" --paginate --jq '.actions_caches[] | select(.key | startswith("lake-knot"))' ; run 37182430320.

  7. jsboige commented on Oct 7, 2026

    @jsboige
    OwnerAuthor

    [CLAIMED] lane myia-po-2026:CoursIA — tapis central du 07/10 02:43Z, file profonde posee par le coordinateur au dispatch (rang 1/2) : ci(lean): les caches .lake de 2,4 Go embarquent les oléans Mathlib déjà servis par lake ex. Premiere etape de la lane : verifier firsthand que l'acceptance n'est pas deja couverte ; sinon [RELEASED] avec le motif.

  8. jsboige commented on Oct 7, 2026

    @jsboige
    OwnerAuthor

    [INFO] candidate-delivered — analyse critère par critère, mesures du 2026-10-07 (lane myia-po-2026:CoursIA, suite dispatch ai-2026-10-07). La clôture revient au coordinateur ou à l'adjoint.

    Le défaut du titre est DÉLIVRÉ — PR #18186 (mergée 2026-09-28T16:24Z, lane myia-ai-01)

    Critère de sortie État mesuré
    1. Somme des caches lake-* sous plafond Délivré côté lakes : 2 412-2 475 Mo → 650-764 Mo par lake (inventaire actions/caches du 07/10 : formal_logic 764, knot 711, argumentation 650). Le geste (rm -rf .lake/packages/mathlib/.lake/build avant la sauvegarde post-job) est mesuré dans le body de #18186 : 8 795 fichiers sur ~9 450 des paquets de knot_lean.
    2. Plus de Cache not found sur clé lake-* à lakefile inchangé, une semaine PAS tenu — mais la cause a changé. Mesuré : run main 37540824088 (06/10 22:31Z), jambe ci de lean-asymmetric-information.yml → Cache not found sur lake-asymmetric_information_lean-Linux-72e51dc…, alors que le lakefile/lean-toolchain n'ont pas bougé depuis ≥ 28/09 (git log vide). La jambe proof-integrity du même run HIT la clé pleine à 22:37 (cache re-sauvé par le ci du run). C'est une évolution, pas le bloat d'oléans : voir §Nouvelle cause.
    3. Jambe à cache chaud non dégradée > 1 min Tenu : lake exe cache get = 37 s mesuré (body #18186, 8 690 fichiers) ; runs knot_lean verts sur main et branche 06-07/10.

    Nouvelle cause mesurée : le quota est saturé par les caches pip de setup-python, plus par les lakes

    Inventaire gh api actions/caches du 07/10 : 20 caches, 10 464 Mo au total sur un quota de 10 Go — le quota est plein, l'éviction LRU frappe donc encore, maintenant sur les caches lake-* et toutes les autres familles.

    Famille Volume Détail
    setup-python pip ~7,9 Go 3 entrées de 1 542 Mo (python 3.9 / 3.11 / 3.12) dupliquées par scope de branche (clés identiques ×2) + une 3.9 à 130 Mo + deux vides
    lake-* 2,1 Go 3 lakes (post-#18186, sains)
    codeql ~0,5 Go borné par #18183 ✓
    node + slides ~0,25 Go —

    Le bloat a donc migré : #18183 a borné les overlays CodeQL, #18186 a vidé les oléans Mathlib des lakes, et la place reprise est consommée par des caches pip de 1,5 Go l'unité (poids typique d'un cache de wheels torch/numpy), dupliqués par version de Python et par scope de branche. Sources repérées : ict-tests.yml:418, ict-tests-profile.yml:89, ml-tests.yml:77 (cache: pip), et 9 workflows au total.

    Recommandation

    Le périmètre du titre (les caches .lake embarquent les oléans Mathlib) est délivré et mesuré ; le critère 2 reste structurellement ouvert pour une cause qui n'existait pas à la rédaction et qui n'est pas un cache lake. Issue suivante ouverte pour ce résiduel : la référence arrive en commentaire dans la minute.

  9. jsboige commented on Oct 9, 2026

    @jsboige
    OwnerAuthor

    [INFO] candidate-delivered -- lane myia-ai-01:CoursIA-2 (tapis c.343)

    Tiree par le tapis (#18832), cette issue est deja livree sur main : je rends la main, la cloture revient au coordinateur ou a l'adjoint.

    Preuve par critere (mesure firsthand sur le checkout local d'origin/main) :

    • Constat d'origine : lean-build.yml:210-214 mettait en cache tout ${project}/.lake oleans Mathlib compris (2,4 Go/lake, 3 lakes = 7,3 Go sur un quota de 10 Go).
    • Le correctif est sur main : rm -rf .lake/packages/mathlib/.lake/build avant la sauvegarde du cache, aux DEUX emplacements d'appel -- .github/workflows/lean-build.yml:321 et :412 -- avec le commentaire « The lake's own build and the other packages stay cached. »
    • PR livreuse : fix(ci,#18185): drop Mathlib oleans before the Lean cache save #18186 fix(ci,#18185): drop Mathlib oleans before the Lean cache save -- MERGED le 2026-09-28T16:24:35Z (fichiers : .github/workflows/lean-build.yml, .github/workflows/lean-axiom.yml).
    • Le probleme expose (cache de 2,4 Go par lake evincant les autres par anciennete, cause des builds a froid de knot_lean) est traite par ce meme geste.

    Le signal de livraison du tapis n'avait pas sonde ce candidat (plafond de sondes atteint, fail-OPEN) -- ce commentaire est la sonde.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions