Skip to content

ci: Date-window sweep est rouge sur main (exit 127 + objet Git illisible) et ne dit rien de lui-meme #16141

Description

@myia-ai-01

Date-window sweep est la seule gate non verte du head courant de main — un check en echec sur 183, et il n'appartient a aucune lane. Je l'ouvre a ce titre.

Mesure

Head main = 767d6fb6aafa5788ba97ff7cc0a74e1f6743a26b. Check-run 103920978619 :

Date-window sweep = failure
started   2026-09-14T09:14:47Z
completed 2026-09-14T09:14:56Z     (9 secondes)
output.title   = (vide)
output.summary = (vide)

Le check ne dit rien de lui-meme : ni titre, ni resume. Toute l'information est dans les annotations :

failure  .github:15   Process completed with exit code 127.
failure  .github:59   Could not read bef197e6f84c83eba4fbc7b5f6e2d7a8db090e34
warning  .github:2    Node.js 20 is deprecated (actions/checkout@v4, actions/setup-python@v5 forces sur Node 24)

Ce que ces deux lignes disent, et ce qu'elles ne disent pas

  • exit code 127 est « command not found » au sens shell. Ce n'est pas une assertion qui echoue : c'est un binaire ou un script que le runner ne trouve pas. Neuf secondes de duree totale vont dans le meme sens — le job meurt avant de faire quoi que ce soit.
  • Could not read bef197e6f84c… nomme un objet Git que le job n'arrive pas a lire. bef197e6f8 est un commit de main (il portait un run vert de Scripts & Notebook-Tools Tests a 2026-09-14T04:02:27Z), donc l'objet existe cote depot. Un checkout peu profond (fetch-depth par defaut = 1) qui tente ensuite de lire un commit anterieur produit exactement cette erreur.

Hypothese, pas diagnostic : un balayage qui remonte une fenetre de dates a besoin de l'historique, et l'obtient d'un checkout qui ne le fournit pas. Je ne l'ai pas etablie — les deux annotations sont compatibles avec plusieurs causes, et le 127 pourrait tout aussi bien etre premier et la lecture d'objet une consequence.

Ce que je n'ai pas fait

  • Je n'ai pas ouvert les logs du run (34826882416) : les annotations pointent .github:15 et .github:59, mais je n'ai pas identifie le fichier de workflow ni les lignes reelles. C'est le premier geste a faire et il decide du reste.
  • Je n'ai pas mesure depuis quand cette gate echoue, ni si elle a deja ete verte. Un organe qui n'a jamais reussi et un organe casse ce matin n'appellent pas le meme correctif.
  • Je n'ai pas regarde si ce sweep est bloquant quelque part (registre fast-lane, pr-gate) ou purement advisory. S'il est bloquant, son exit 127 rougit des PRs pour une raison qui n'a rien a voir avec elles — c'est la classe de defaut de fix(ci,#15853): relever le plafond de Scripts Tests (CPU) de 20 a 30 min #16087.

Pourquoi ca compte au-dela du rouge lui-meme

Un check qui rend failure avec un output vide ne peut pas etre diagnostique depuis l'interface : il faut descendre aux annotations pour apprendre quoi que ce soit. Quelle que soit la cause, faire ecrire a ce sweep ce qu'il a tente et sur quoi il a bute vaut le detour — sans quoi le prochain qui le regarde repart de zero.

Criteres de sortie

  • Le fichier de workflow et les lignes reelles derriere .github:15 / .github:59 sont nommes
  • La cause du 127 est etablie (binaire absent ? script deplace ? PATH ?), pas supposee
  • La lecture d'objet est tranchee : profondeur de checkout, ou objet reellement absent
  • Le statut bloquant/advisory du check est mesure, et dit dans le grain
  • Le check rend un output.summary non vide en cas d'echec

See #16087.

Activity

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