CI: audit.yml n'a jamais ete declenche — aucun run schedule depuis son merge #314

New issue

Closed

opened 2026-07-27 23:40:43 +00:00 by maximus · 1 comment

maximus commented

2026-07-27 23:40:43 +00:00

Owner

audit.yml (ajoute par #232, merge le 2026-07-25) declare schedule: cron '0 6 * * *'. Il n'a jamais tourne.

Sur les 420 taches de l'historique Actions du repo, les seuls evenements presents sont push et pull_request — zero schedule. Les fenetres 06:00 UTC des 25, 26 et 27 juillet sont toutes passees sans declenchement.

timeout 8 curl -s -H "Authorization: token $TOKEN" "$API/actions/tasks?limit=30" \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); \
    print({r["event"] for r in d["workflow_runs"]})'
-> {'pull_request', 'push'}

Pourquoi ca compte

audit.yml est le canal de notification pour les advisories publiees entre deux PR Rust — check-rust.yml ne tourne que sur ~1 PR sur 40. Tant que le cron ne part pas, cette couverture n'existe pas, quel que soit l'etat vert ou rouge du workflow.

Consequence directe : un workflow_dispatch manuel vert (comme celui de #310) prouve que la commande sort en 0, pas que l'alarme quotidienne fonctionne. Les deux ne doivent pas etre confondus.

Pistes

Le scheduler Forgejo Actions doit etre actif cote instance ; verifier la configuration du serveur.
Sur Forgejo, un workflow schedule n'est pris en compte que s'il est present sur la branche par defaut — c'est le cas ici (main), donc ce n'est pas la cause.
Verifier si le runner (capacite 1) accepte les jobs declenches par le scheduler.
Confirmer si d'autres repos de l'ecosysteme ont des workflows schedule qui partent bien, pour distinguer un probleme d'instance d'un probleme de repo.

Releve pendant #310.

`audit.yml` (ajoute par #232, merge le 2026-07-25) declare `schedule: cron '0 6 * * *'`. **Il n'a jamais tourne.** Sur les **420 taches** de l'historique Actions du repo, les seuls evenements presents sont `push` et `pull_request` — **zero `schedule`**. Les fenetres 06:00 UTC des 25, 26 et 27 juillet sont toutes passees sans declenchement. ``` timeout 8 curl -s -H "Authorization: token $TOKEN" "$API/actions/tasks?limit=30" \ | python3 -c 'import sys,json; d=json.load(sys.stdin); \ print({r["event"] for r in d["workflow_runs"]})' -> {'pull_request', 'push'} ``` ## Pourquoi ca compte `audit.yml` est le canal de notification pour les advisories publiees entre deux PR Rust — `check-rust.yml` ne tourne que sur ~1 PR sur 40. Tant que le cron ne part pas, cette couverture **n'existe pas**, quel que soit l'etat vert ou rouge du workflow. Consequence directe : un `workflow_dispatch` manuel vert (comme celui de #310) prouve que la commande sort en 0, **pas** que l'alarme quotidienne fonctionne. Les deux ne doivent pas etre confondus. ## Pistes - Le scheduler Forgejo Actions doit etre actif cote instance ; verifier la configuration du serveur. - Sur Forgejo, un workflow `schedule` n'est pris en compte que s'il est present sur la **branche par defaut** — c'est le cas ici (`main`), donc ce n'est pas la cause. - Verifier si le runner (capacite 1) accepte les jobs declenches par le scheduler. - Confirmer si d'autres repos de l'ecosysteme ont des workflows `schedule` qui partent bien, pour distinguer un probleme d'instance d'un probleme de repo. Releve pendant #310.

maximus added the

status:ready

type:infra

source:analyste

labels 2026-07-27 23:40:43 +00:00

maximus referenced this issue

2026-07-27 23:46:11 +00:00

fix(deps): clear 6 reachable RustSec advisories, accept 3 unreachable ones #316

maximus referenced this issue

2026-08-14 19:50:29 +00:00

fix(deps): resolve the quick-xml advisories, unyank deep-link and spin #321

maximus commented

2026-08-15 16:42:22 +00:00

Author

Owner

Fermée — la prémisse ne tient pas : le scheduler fonctionne

L'issue affirme « aucun run schedule depuis son merge ». C'est mesurable, et c'est faux : audit.yml se déclenche tous les jours à 06:00 UTC, sans exception, depuis le lendemain de son merge.

19 runs schedule consécutifs, tous verts (GET /actions/tasks, filtre name == "audit") :

run	event	date
339	`schedule`	2026-07-28T06:00:13Z
340–355	`schedule`	2026-07-29 → 2026-08-13, un par jour à 06:00:1xZ
365	`schedule`	2026-08-14T06:00:13Z
369	`schedule`	2026-08-15T06:00:12Z

Aucun trou, aucun échec.

Pourquoi le constat d'origine était vide

Le run de référence cité comme preuve que « seul le workflow_dispatch fonctionne » est le 333, lancé le 2026-07-27 à 23:56:35Z. Le premier tir programmé possible était le lendemain 06:00 UTC — soit le run 339, ~6 h plus tard.

L'issue a donc été écrite dans la fenêtre où le scheduler n'avait pas encore eu l'occasion de s'exprimer. Le « zéro run schedule sur 420 tâches » décrivait un workflow mergé quelques heures plus tôt, pas un scheduler en panne. Rien à réparer : la couverture quotidienne existe et fonctionne depuis le premier jour.

Effet de bord utile

Ces 19 runs verts sont aussi une confirmation indépendante que .cargo/audit.toml est bien lu en conteneur sur main — c'était le point ouvert de l'ADR 0018, et il n'avait été vérifié que par un workflow_dispatch sur une branche.

Le seul suivi qui reste sur ce terrain est #319 (déclencheur de retrait pour rsa), désormais la seule entrée de la liste acceptée depuis le merge de #321 — le garde-fou est passé de 4 à 2 vérifications.

Constaté en mergeant #321/#322 le 2026-08-15.

## Fermée — la prémisse ne tient pas : le scheduler fonctionne L'issue affirme « aucun run `schedule` depuis son merge ». C'est mesurable, et c'est faux : `audit.yml` se déclenche **tous les jours à 06:00 UTC**, sans exception, depuis le lendemain de son merge. **19 runs `schedule` consécutifs, tous verts** (`GET /actions/tasks`, filtre `name == "audit"`) : | run | event | date | |---|---|---| | 339 | `schedule` | 2026-07-28T06:00:13Z | | 340–355 | `schedule` | 2026-07-29 → 2026-08-13, un par jour à 06:00:1xZ | | 365 | `schedule` | 2026-08-14T06:00:13Z | | 369 | `schedule` | 2026-08-15T06:00:12Z | Aucun trou, aucun échec. ## Pourquoi le constat d'origine était vide Le run de référence cité comme preuve que « seul le `workflow_dispatch` fonctionne » est le **333**, lancé le **2026-07-27 à 23:56:35Z**. Le premier tir programmé possible était le lendemain 06:00 UTC — soit le run 339, **~6 h plus tard**. L'issue a donc été écrite dans la fenêtre où le scheduler n'avait pas encore eu l'occasion de s'exprimer. Le « zéro run `schedule` sur 420 tâches » décrivait un workflow mergé quelques heures plus tôt, pas un scheduler en panne. Rien à réparer : la couverture quotidienne existe et fonctionne depuis le premier jour. ## Effet de bord utile Ces 19 runs verts sont aussi une confirmation indépendante que `.cargo/audit.toml` est bien lu en conteneur sur `main` — c'était le point ouvert de l'[ADR 0018](../src/branch/main/docs/adr/0018-suppression-advisories-non-atteignables.md), et il n'avait été vérifié que par un `workflow_dispatch` sur une branche. Le seul suivi qui reste sur ce terrain est **#319** (déclencheur de retrait pour `rsa`), désormais la seule entrée de la liste acceptée depuis le merge de #321 — le garde-fou est passé de 4 à 2 vérifications. Constaté en mergeant #321/#322 le 2026-08-15.

maximus closed this issue

2026-08-15 16:42:22 +00:00

maximus referenced this issue from a commit

2026-08-15 16:42:40 +00:00

state: close #314 — audit.yml scheduler was never broken