Suivis de la revue de #418 : latest.json vide accepté sous jq 1.6, appel du filtre non testé, paths-ignore de check-frontend

maximus commented

2026-10-12 19:34:25 +00:00

Owner

Suivis non bloquants de la revue de la PR #418 (commentaire 22774, verdict APPROVE), sur décision de Max le 2026-10-12 : la pile #414 → #418 a été mergée telle quelle, ses suivis vivent ici. Le point 1 est à faire avant le prochain tag.

1. `check-latest-json.jq` accepte un `latest.json` vide sous jq 1.6 (avant le prochain tag)

Mesuré le 2026-10-12, jq -e --arg version 0.17.1 -f scripts/check-latest-json.jq <fichier> :

fichier	jq 1.6 (conteneur de release, CI)	jq 1.7
vide	rc 0, passe	rc 4
deux documents JSON, le dernier valide	rc 0, passe	rc 0, passe

Le job ferait alors le DELETE puis le PUT d'un fichier vide sur le registre. Inatteignable aujourd'hui : si scripts/build-latest-json.sh échoue, l'étape « Generate latest.json » arrête le job avant « Publish », et le script n'écrit qu'un document. Défaut déjà présent dans l'assertion en ligne de #416.

Correctif testé par le relecteur : -s aux deux appels (release.yml et le helper check() du test), filtre enveloppé dans length == 1 and (.[0] | …), plus deux tests (vide, deux documents) ; 30/30 sous jq 1.6 et 1.7. Sans le correctif, ces deux tests ne rougissent que sous jq 1.6, donc en CI.

2. « À chaque PR » est trop large

check-frontend.yml ignore .claude/** et release.yml. Une PR qui ne touche que verify-release.sh (ou que release.yml) ne lance donc pas scripts/build-latest-json.test.mjs, qui compare les trois listes de clés. Soit corriger la formulation (en-têtes de check-latest-json.jq et du test, docs/architecture.md, skill /release), soit retirer .claude/** du paths-ignore (à trancher : coût d'un run frontend sur les PR de skills).

3. Commentaire périmé dans `release.yml:104`

Il parle encore d'un repli .deb (clé générique retirée par #418).

4. L'appel du filtre par `release.yml` n'est pas testé

Retirer -e de l'appel dans l'étape « Publish » laisse passer la clé générique et une mauvaise version, et les 28 tests restent verts : seul le fichier .jq est exercé. Piste : un test qui extrait le texte exact du run: de l'étape (PyYAML ou équivalent JS) et le lance avec un curl factice, comme le harnais de la PR #418 (nominal : DELETE puis PUT ; manifestes fautifs : exit 1, aucun appel).

5. `tauri dev` sous Linux

Un binaire sans marqueur de paquet ne cherche que linux-x86_64, retirée par #418 : un build tauri dev sous Linux affichera une erreur (TargetsNotFound) à chaque vérification de mise à jour. Une ligne dans docs/qa-update-cycle.md évitera de la prendre pour une régression.

Hors dépôt : `la-compagnie-maximus/docs/forgejo-ops.md`

/actions/tasks n'ignore limit que sans page (613 lignes sans page, 5 avec ?limit=5&page=2, 30 avec ?page=2, mesuré le 2026-10-12) : l'exemple ?limit=5 y induit en erreur.
Cas mesuré par la revue de #414 (22219) : f19b027 poussé sans forcer pendant que le run 513 de check-rust tournait, clé concurrency en place avec cancel-in-progress: true, et le run 513 est allé au bout au lieu d'être annulé.

Critères d'acceptation

Sous jq 1.6 et 1.7, le contrôle refuse un fichier vide et un fichier à deux documents ; deux tests le prouvent ; release.yml appelle le filtre avec -s.
La formulation « à chaque PR » ou le paths-ignore de check-frontend est tranché et cohérent.
release.yml:104 ne parle plus de repli.
L'appel du filtre dans « Publish » est couvert par un test, ou la raison de ne pas le faire est écrite.
docs/qa-update-cycle.md mentionne l'erreur attendue d'un build tauri dev sous Linux.

Liens

PR #418 (revue 22774), #320, PR #416 (revue 22437).

Suivis non bloquants de la revue de la PR #418 (commentaire 22774, verdict APPROVE), sur décision de Max le 2026-10-12 : la pile #414 → #418 a été mergée telle quelle, ses suivis vivent ici. **Le point 1 est à faire avant le prochain tag.** ## 1. `check-latest-json.jq` accepte un `latest.json` vide sous jq 1.6 (avant le prochain tag) Mesuré le 2026-10-12, `jq -e --arg version 0.17.1 -f scripts/check-latest-json.jq <fichier>` : | fichier | jq 1.6 (conteneur de release, CI) | jq 1.7 | |---|---|---| | vide | rc 0, **passe** | rc 4 | | deux documents JSON, le dernier valide | rc 0, **passe** | rc 0, **passe** | Le job ferait alors le `DELETE` puis le `PUT` d'un fichier vide sur le registre. **Inatteignable aujourd'hui** : si `scripts/build-latest-json.sh` échoue, l'étape « Generate latest.json » arrête le job avant « Publish », et le script n'écrit qu'un document. Défaut déjà présent dans l'assertion en ligne de #416. Correctif testé par le relecteur : `-s` aux deux appels (`release.yml` et le helper `check()` du test), filtre enveloppé dans `length == 1 and (.[0] | …)`, plus deux tests (vide, deux documents) ; 30/30 sous jq 1.6 et 1.7. Sans le correctif, ces deux tests ne rougissent que sous jq 1.6, donc en CI. ## 2. « À chaque PR » est trop large `check-frontend.yml` ignore `.claude/**` et `release.yml`. Une PR qui ne touche que `verify-release.sh` (ou que `release.yml`) ne lance donc pas `scripts/build-latest-json.test.mjs`, qui compare les trois listes de clés. Soit corriger la formulation (en-têtes de `check-latest-json.jq` et du test, `docs/architecture.md`, skill `/release`), soit retirer `.claude/**` du `paths-ignore` (à trancher : coût d'un run frontend sur les PR de skills). ## 3. Commentaire périmé dans `release.yml:104` Il parle encore d'un repli `.deb` (clé générique retirée par #418). ## 4. L'appel du filtre par `release.yml` n'est pas testé Retirer `-e` de l'appel dans l'étape « Publish » laisse passer la clé générique et une mauvaise version, et les 28 tests restent verts : seul le fichier `.jq` est exercé. Piste : un test qui extrait le texte exact du `run:` de l'étape (PyYAML ou équivalent JS) et le lance avec un `curl` factice, comme le harnais de la PR #418 (nominal : `DELETE` puis `PUT` ; manifestes fautifs : exit 1, aucun appel). ## 5. `tauri dev` sous Linux Un binaire sans marqueur de paquet ne cherche que `linux-x86_64`, retirée par #418 : un build `tauri dev` sous Linux affichera une erreur (`TargetsNotFound`) à chaque vérification de mise à jour. Une ligne dans `docs/qa-update-cycle.md` évitera de la prendre pour une régression. ## Hors dépôt : `la-compagnie-maximus/docs/forgejo-ops.md` - `/actions/tasks` n'ignore `limit` que sans `page` (613 lignes sans `page`, 5 avec `?limit=5&page=2`, 30 avec `?page=2`, mesuré le 2026-10-12) : l'exemple `?limit=5` y induit en erreur. - Cas mesuré par la revue de #414 (22219) : `f19b027` poussé sans forcer pendant que le run 513 de `check-rust` tournait, clé `concurrency` en place avec `cancel-in-progress: true`, et le run 513 est allé au bout au lieu d'être annulé. ## Critères d'acceptation - [ ] Sous jq 1.6 et 1.7, le contrôle refuse un fichier vide et un fichier à deux documents ; deux tests le prouvent ; `release.yml` appelle le filtre avec `-s`. - [ ] La formulation « à chaque PR » ou le `paths-ignore` de `check-frontend` est tranché et cohérent. - [ ] `release.yml:104` ne parle plus de repli. - [ ] L'appel du filtre dans « Publish » est couvert par un test, ou la raison de ne pas le faire est écrite. - [ ] `docs/qa-update-cycle.md` mentionne l'erreur attendue d'un build `tauri dev` sous Linux. ## Liens PR #418 (revue 22774), #320, PR #416 (revue 22437).