eqs check : une tâche ne peut pas déclarer qu'elle lit la sortie d'une autre, et la porte rougit par intermittence #117

Closed
opened 2026-10-06 13:30:41 +00:00 by nicolas-fryder · 0 comments

Ce qui se passe

eqs check joue toutes les tâches en parallèle :

resultats.push(...(await Promise.all(taches.map((t) => lancer(t, root, env)))))

Le schéma de tâche (nom, cmd, requiert, budget) n'a aucun champ pour dire « celle-ci lit ce que celle-là écrit ». Il n'y a que --sequential, qui est tout ou rien et paie le prix fort.

Sur nuage, la tâche maison gates contient un contrôle de budget de bundle qui lit apps/front/.next/build-manifest.json et les chunks qu'il désigne. La tâche build:front du socle réécrit ce dossier au même moment. Une fois sur deux environ, le manifeste est là mais les chunks pas encore :

  ✗ gates      10.3s
  Échec : gates

...et relancée seule, immédiatement après, la tâche passe. Deux fois dans la même journée j'ai cherché ailleurs avant de trouver.

Reproduit

// le manifeste existe, les chunks pas encore — exactement l'état de mi-build
fs.renameSync('apps/front/.next/static', 'apps/front/.next/static.bak')
  ✗ bundle-size (1)
      Aucun chunk mesuré — le build est-il complet ?

Ce que ça coûte

Une porte rouge par intermittence est pire qu'une porte rouge : on la relance, elle passe, et on apprend à ne plus la croire. C'est le contraire de ce que eqs check est là pour faire.

Et le problème est plus large que mon cas : toute tâche qui veut MESURER une sortie de build — taille d'un bundle, nombre de routes, poids d'une image, contenu d'un dist — est dans la même situation. Aujourd'hui la seule issue est de sortir la tâche de la porte.

Contournement en place chez nuage

bundle-size est retiré de la liste par défaut de run-all.mjs (il reste jouable par son nom) et appelé depuis pre-push, après pnpm check. La porte le dit à voix haute plutôt que de le faire disparaître :

  – bundle-size (lit `.next` que `build:front` réécrit en parallèle — joué dans pre-push, après la porte)

Le bénéfice de bord : il mesure enfin le build qui vient d'être fait, au lieu du précédent.

Ce que je propose

Un champ apres: string[] sur la tâche, et un ordonnancement par vagues : tout ce qui n'a pas de dépendance part ensemble, le reste attend ses prédécesseurs. Quelques lignes au-dessus du Promise.all existant, et le budget global n'en souffre pas — les tâches dépendantes sont rares.

À défaut, un champ sequentielApres: true qui ferait simplement tourner la tâche après toutes les autres suffirait à mon cas et à la plupart.

Contexte

Relevé pendant le rétrofit du socle sur nuage (0.14.0), même journée que #115 et #116.

## Ce qui se passe `eqs check` joue toutes les tâches en parallèle : ```js resultats.push(...(await Promise.all(taches.map((t) => lancer(t, root, env))))) ``` Le schéma de tâche (`nom`, `cmd`, `requiert`, `budget`) n'a aucun champ pour dire « celle-ci lit ce que celle-là écrit ». Il n'y a que `--sequential`, qui est tout ou rien et paie le prix fort. Sur nuage, la tâche maison `gates` contient un contrôle de budget de bundle qui lit `apps/front/.next/build-manifest.json` et les chunks qu'il désigne. La tâche `build:front` du socle **réécrit ce dossier au même moment**. Une fois sur deux environ, le manifeste est là mais les chunks pas encore : ``` ✗ gates 10.3s Échec : gates ``` ...et relancée seule, immédiatement après, la tâche passe. Deux fois dans la même journée j'ai cherché ailleurs avant de trouver. ## Reproduit ```js // le manifeste existe, les chunks pas encore — exactement l'état de mi-build fs.renameSync('apps/front/.next/static', 'apps/front/.next/static.bak') ``` ``` ✗ bundle-size (1) Aucun chunk mesuré — le build est-il complet ? ``` ## Ce que ça coûte Une porte rouge par intermittence est pire qu'une porte rouge : on la relance, elle passe, et on apprend à ne plus la croire. C'est le contraire de ce que `eqs check` est là pour faire. Et le problème est plus large que mon cas : toute tâche qui veut MESURER une sortie de build — taille d'un bundle, nombre de routes, poids d'une image, contenu d'un `dist` — est dans la même situation. Aujourd'hui la seule issue est de sortir la tâche de la porte. ## Contournement en place chez nuage `bundle-size` est retiré de la liste par défaut de `run-all.mjs` (il reste jouable par son nom) et appelé depuis `pre-push`, après `pnpm check`. La porte le dit à voix haute plutôt que de le faire disparaître : ``` – bundle-size (lit `.next` que `build:front` réécrit en parallèle — joué dans pre-push, après la porte) ``` Le bénéfice de bord : il mesure enfin le build qui vient d'être fait, au lieu du précédent. ## Ce que je propose Un champ `apres: string[]` sur la tâche, et un ordonnancement par vagues : tout ce qui n'a pas de dépendance part ensemble, le reste attend ses prédécesseurs. Quelques lignes au-dessus du `Promise.all` existant, et le budget global n'en souffre pas — les tâches dépendantes sont rares. À défaut, un champ `sequentielApres: true` qui ferait simplement tourner la tâche après toutes les autres suffirait à mon cas et à la plupart. ## Contexte Relevé pendant le rétrofit du socle sur nuage (0.14.0), même journée que #115 et #116.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-platform#117
No description provided.