check.yml : le lint typé d'un satellite moyen ne tient pas dans les 2 Go du runner (SIGABRT, tas V8 plein)

nicolas-fryder commented

2026-10-15 10:56:45 +00:00

Owner

Constat (ATLAS, `check.yml@v1`, run du 2026-10-15 sur `542d9ec`)

pnpm check --sequential : la tâche lint meurt « tuée par le système (SIGABRT), sans avoir pu rien dire ». Ce n'est pas le noyau (ce serait SIGKILL) : c'est V8 qui abandonne, tas plein. En série, comme le workflow le fait déjà, le lint est seul et meurt quand même.

Mesuré en local (même dépôt, socle 0.24.0, ESLint 9.39, sans cache)

node --max-old-space-size=1024 node_modules/eslint/bin/eslint.js .   → exit 134 (SIGABRT)
node --max-old-space-size=1536 …                                     → exit 134
node --max-old-space-size=1792 …                                     → exit 134
node --max-old-space-size=3072 …                                     → exit 0

783 fichiers TS/JS. Le profil next() de @eqs/tooling active projectService : un programme TypeScript complet par tsconfig.json rencontré. Chez ATLAS, il y en a trois (racine, tests/ qui inclut aussi src, worker/), chacun avec les types de Next 16 et de Prisma. Le tas nécessaire est donc entre 1,8 et 3 Go. Avec le runner à 2 Go et 1,5 CPU (commentaire de check.yml), aucun réglage de --max-old-space-size ne peut suffire : au-delà de ce que le conteneur a, c'est le noyau qui tue.

Conséquence

check est rouge à chaque push sur ATLAS, et integration, contract et audit, qui en dépendent (needs), ne tournent jamais. Le hook pre-push local (sans plafond) passe.

Pistes

une étiquette de runner plus grosse pour check (4 Go), en entrée du workflow (runs-on) ;
ou une entrée node-options transmise à pnpm check, utile seulement avec un runner plus grand ;
ou, côté @eqs/tooling, un lint typé découpé par tsconfig (un processus par programme), qui borne le pic à un seul programme.

Ouvert depuis une session de travail sur ATLAS.

## Constat (ATLAS, `check.yml@v1`, run du 2026-10-15 sur `542d9ec`) `pnpm check --sequential` : la tâche `lint` meurt **« tuée par le système (SIGABRT), sans avoir pu rien dire »**. Ce n'est pas le noyau (ce serait SIGKILL) : c'est V8 qui abandonne, tas plein. En série, comme le workflow le fait déjà, le lint est seul et meurt quand même. ## Mesuré en local (même dépôt, socle 0.24.0, ESLint 9.39, sans cache) ``` node --max-old-space-size=1024 node_modules/eslint/bin/eslint.js . → exit 134 (SIGABRT) node --max-old-space-size=1536 … → exit 134 node --max-old-space-size=1792 … → exit 134 node --max-old-space-size=3072 … → exit 0 ``` 783 fichiers TS/JS. Le profil `next()` de `@eqs/tooling` active `projectService` : un programme TypeScript complet par `tsconfig.json` rencontré. Chez ATLAS, il y en a trois (racine, `tests/` qui inclut aussi `src`, `worker/`), chacun avec les types de Next 16 et de Prisma. Le tas nécessaire est donc **entre 1,8 et 3 Go**. Avec le runner à 2 Go et 1,5 CPU (commentaire de `check.yml`), **aucun réglage de `--max-old-space-size` ne peut suffire** : au-delà de ce que le conteneur a, c'est le noyau qui tue. ## Conséquence `check` est rouge à chaque push sur ATLAS, et `integration`, `contract` et `audit`, qui en dépendent (`needs`), ne tournent jamais. Le hook `pre-push` local (sans plafond) passe. ## Pistes - une étiquette de runner plus grosse pour `check` (4 Go), en entrée du workflow (`runs-on`) ; - ou une entrée `node-options` transmise à `pnpm check`, utile seulement avec un runner plus grand ; - ou, côté `@eqs/tooling`, un lint typé découpé par `tsconfig` (un processus par programme), qui borne le pic à un seul programme. *Ouvert depuis une session de travail sur ATLAS.*

nicolas-fryder referenced this issue from Infrastructure/forgejo-runner

2026-10-15 12:10:42 +00:00

Jobs à 4 Go de RAM : le lint typé d'ATLAS meurt à 3 Go (SIGABRT), et check bloque tout le reste #1

nicolas-fryder commented

2026-10-15 12:10:50 +00:00

Author

Owner

Correction : les jobs ont 3 Go depuis le 2026-10-14 (forgejo-runner, config.yml), pas 2. Le chiffre venait du commentaire de check.yml, qui est périmé et serait à mettre à jour. Le lint meurt quand même à 3 Go : demande de passage à 4 Go ouverte en Infrastructure/forgejo-runner#1.

Correction : les jobs ont **3 Go** depuis le 2026-10-14 (`forgejo-runner`, `config.yml`), pas 2. Le chiffre venait du commentaire de `check.yml`, qui est périmé et serait à mettre à jour. Le lint meurt quand même à 3 Go : demande de passage à 4 Go ouverte en Infrastructure/forgejo-runner#1.

nicolas-fryder commented

2026-10-15 12:47:10 +00:00

Author

Owner

Cause mesurée (détail dans Infrastructure/forgejo-runner#1) : à 3 Go, Node 22 fixe son tas à 1 584 Mo, et le lint d'ATLAS en demande ~1,8 Go. V8 abandonne alors que le cgroup a encore plus d'un gigaoctet libre (oom_kill 0). Avec NODE_OPTIONS=--max-old-space-size=2560, le job passe à 3 Go, avec un pic anonyme de 2 519 Mo.

Côté workflow, deux choses suffiraient si le runner ne pose pas NODE_OPTIONS lui-même :

une entrée node-options dans check.yml (et integration.yml, mutation.yml), transmise en env aux étapes Node ;
corriger le commentaire « le runner donne 2 Go et 1,5 CPU », périmé depuis le 2026-10-14 (3 Go, 2,5 CPU).

Cause mesurée (détail dans Infrastructure/forgejo-runner#1) : à 3 Go, **Node 22 fixe son tas à 1 584 Mo**, et le lint d'ATLAS en demande ~1,8 Go. V8 abandonne alors que le cgroup a encore plus d'un gigaoctet libre (`oom_kill 0`). Avec `NODE_OPTIONS=--max-old-space-size=2560`, le job passe à 3 Go, avec un pic anonyme de 2 519 Mo. Côté workflow, deux choses suffiraient si le runner ne pose pas `NODE_OPTIONS` lui-même : - une entrée `node-options` dans `check.yml` (et `integration.yml`, `mutation.yml`), transmise en `env` aux étapes Node ; - corriger le commentaire « le runner donne 2 Go et 1,5 CPU », périmé depuis le 2026-10-14 (3 Go, 2,5 CPU).

nicolas-fryder referenced this issue

2026-10-15 13:05:14 +00:00

check.yml : le commentaire dit les vraies limites du runner (3 Go, 2,5 CPU, tas de 2 560 Mo) #5

nicolas-fryder referenced this issue from a commit

2026-10-15 13:05:14 +00:00

check.yml : le commentaire dit les vraies limites du runner (3 Go, 2,5 CPU, tas de 2 560 Mo)

nicolas-fryder commented

2026-10-15 13:05:27 +00:00

Author

Owner

Réglé côté runner, déployé (Infrastructure/forgejo-runner 376e8ad) : chaque job reçoit NODE_OPTIONS=--max-old-space-size=2560 (runner.envs de config.yml, à côté du plafond de 3 Go qu'il accompagne). Rien à changer dans check.yml ni dans les satellites.

Vérifié avant de pousser :

le harnais e2e du runner contrôle maintenant que le job reçoit exactement la valeur déclarée dans config.yml — 29/29 ;
next build d'eqs-demo à 3 Go, trois workers comme sur le VPS : passe avec un pic plus bas (1 771 Mo contre 2 123 Mo sans réglage) ;
le lint d'ATLAS à 2 560 Mo : déjà mesuré dans forgejo-runner#1 (pic 2 519 Mo).

Le commentaire périmé de check.yml (« 2 Go et 1,5 CPU ») est corrigé dans #5.

Il reste à relancer la CI d'ATLAS pour le constater sur pièces ; je laisse ce ticket ouvert jusque-là.

🤖 Generated with Claude Code

Réglé côté runner, déployé (Infrastructure/forgejo-runner `376e8ad`) : chaque job reçoit `NODE_OPTIONS=--max-old-space-size=2560` (`runner.envs` de `config.yml`, à côté du plafond de 3 Go qu'il accompagne). Rien à changer dans `check.yml` ni dans les satellites. Vérifié avant de pousser : - le harnais e2e du runner contrôle maintenant que le job reçoit exactement la valeur déclarée dans `config.yml` — 29/29 ; - `next build` d'eqs-demo à 3 Go, trois workers comme sur le VPS : passe avec un pic **plus bas** (1 771 Mo contre 2 123 Mo sans réglage) ; - le lint d'ATLAS à 2 560 Mo : déjà mesuré dans forgejo-runner#1 (pic 2 519 Mo). Le commentaire périmé de `check.yml` (« 2 Go et 1,5 CPU ») est corrigé dans #5. Il reste à relancer la CI d'ATLAS pour le constater sur pièces ; je laisse ce ticket ouvert jusque-là. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nicolas-fryder commented

2026-10-15 14:10:19 +00:00

Author

Owner

Constaté sur pièces : la CI de relance d'ATLAS (EQS/ATLAS#7, run #14) a check vert, lint compris, avec le tas de 2 560 Mo que pose le runner. Je ferme.

Les jobs qui suivent check ont enfin tourné chez ATLAS (integration, contract) ; leurs rouges sont un autre sujet, sans lien avec la mémoire.

🤖 Generated with Claude Code

Constaté sur pièces : la CI de relance d'ATLAS (EQS/ATLAS#7, run #14) a **`check` vert**, lint compris, avec le tas de 2 560 Mo que pose le runner. Je ferme. Les jobs qui suivent `check` ont enfin tourné chez ATLAS (`integration`, `contract`) ; leurs rouges sont un autre sujet, sans lien avec la mémoire. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nicolas-fryder closed this issue

2026-10-15 14:10:21 +00:00

Rows
Columns

check.yml : le lint typé d'un satellite moyen ne tient pas dans les 2 Go du runner (SIGABRT, tas V8 plein) #4

Constat (ATLAS, check.yml@v1, run du 2026-10-15 sur 542d9ec)

Mesuré en local (même dépôt, socle 0.24.0, ESLint 9.39, sans cache)

Conséquence

Pistes

Constat (ATLAS, `check.yml@v1`, run du 2026-10-15 sur `542d9ec`)