L'étape audit de reusable-ci-node.yml porte déjà un garde-fou pour ne pas bloquer sur un service que l'on sait hors d'usage. Il ne couvre qu'une partie des modes d'échec, et laisse passer celui qui se produit réellement.
Le garde actuel
if [ "$EXIT" -ne 0 ] && printf '%s' "$OUT" | grep -qE 'responded with 410|endpoint is being retired'; then
echo "::warning title=Dependency audit skipped::..."
exit 0
fi
exit $EXIT
Deux motifs, tous deux propres à l'ancien point d'accès retiré le 15 juillet.
Le mode d'échec qui passe au travers
pnpm interroge désormais le point d'accès de remplacement, qui répond mal par intermittence. La sortie est alors :
[WARN] POST https://registry.npmjs.org/-/npm/v1/security/advisories/bulk error (23). Will retry in 10 seconds. 2 retries left.
[WARN] POST https://registry.npmjs.org/-/npm/v1/security/advisories/bulk error (23). Will retry in 1 minute. 1 retries left.
##[error]Process completed with exit code 1.
Ni 410, ni « endpoint is being retired ». Le grep ne matche pas, l'étape sort en 1, et le job échoue.
L'intention du garde est explicite dans son propre message : « it is reporting a warning instead of failing », parce que cette étape « cannot gate anything » tant que le dépôt n'est pas passé à pnpm 11. Aujourd'hui elle bloque quand même, simplement par un autre chemin.
Ce que ça coûte
FerrFleet-Cloud#738 est une PR exclusivement Rust (trois fichiers dans api/src). Elle a été bloquée trois relances de suite par ce job, sur un dépôt dont main est vert. Un gate qui dépend d'un service tiers instable et qui échoue au lieu d'avertir bloque des PR au hasard, y compris celles qui ne touchent pas une ligne de JavaScript.
Correction proposée
Élargir le motif pour couvrir l'échec du point d'accès de remplacement, pas seulement le retrait de l'ancien :
grep -qE 'responded with 410|endpoint is being retired|security/advisories/bulk'
Un échec sur security/advisories/bulk est par nature un échec de service, jamais un rapport de vulnérabilité, donc l'élargissement ne masque aucun résultat réel. Le message d'avertissement existant reste juste tel quel.
À arbitrer par ailleurs, et c'est le vrai fond : tant que pnpm audit ne peut rien garantir, enable-audit mériterait peut-être d'être coupé chez les consommateurs plutôt que laissé actif avec un garde-fou qu'il faut élargir à chaque nouveau mode de panne. Les CVE de dépendances restent couvertes par osv-scanner dans le workflow security-scan, ce que le message du garde rappelle lui-même.
L'étape
auditdereusable-ci-node.ymlporte déjà un garde-fou pour ne pas bloquer sur un service que l'on sait hors d'usage. Il ne couvre qu'une partie des modes d'échec, et laisse passer celui qui se produit réellement.Le garde actuel
Deux motifs, tous deux propres à l'ancien point d'accès retiré le 15 juillet.
Le mode d'échec qui passe au travers
pnpm interroge désormais le point d'accès de remplacement, qui répond mal par intermittence. La sortie est alors :
Ni
410, ni « endpoint is being retired ». Legrepne matche pas, l'étape sort en 1, et le job échoue.L'intention du garde est explicite dans son propre message : « it is reporting a warning instead of failing », parce que cette étape « cannot gate anything » tant que le dépôt n'est pas passé à pnpm 11. Aujourd'hui elle bloque quand même, simplement par un autre chemin.
Ce que ça coûte
FerrFleet-Cloud#738 est une PR exclusivement Rust (trois fichiers dans
api/src). Elle a été bloquée trois relances de suite par ce job, sur un dépôt dontmainest vert. Un gate qui dépend d'un service tiers instable et qui échoue au lieu d'avertir bloque des PR au hasard, y compris celles qui ne touchent pas une ligne de JavaScript.Correction proposée
Élargir le motif pour couvrir l'échec du point d'accès de remplacement, pas seulement le retrait de l'ancien :
grep -qE 'responded with 410|endpoint is being retired|security/advisories/bulk'Un échec sur
security/advisories/bulkest par nature un échec de service, jamais un rapport de vulnérabilité, donc l'élargissement ne masque aucun résultat réel. Le message d'avertissement existant reste juste tel quel.À arbitrer par ailleurs, et c'est le vrai fond : tant que
pnpm auditne peut rien garantir,enable-auditmériterait peut-être d'être coupé chez les consommateurs plutôt que laissé actif avec un garde-fou qu'il faut élargir à chaque nouveau mode de panne. Les CVE de dépendances restent couvertes parosv-scannerdans le workflowsecurity-scan, ce que le message du garde rappelle lui-même.