refonte(pc-mirror) : le signalement de la forge passe en bash #14
Loading…
Reference in a new issue
No description provided.
Delete branch "refonte/signalement-bash"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce que fait cette branche
deploy/signalement.pydevientdeploy/signalement.sh: la livraison ne porteplus une ligne de Python.
curlfait les appels,jqlit les réponses — exigé audémarrage, pour le dire tout de suite plutôt que d'échouer sur un JSON illisible.
Le contrat ne bouge pas : mêmes arguments, mêmes messages, mêmes codes de
sortie. Les trois appels de
livraison.ymlet les quatre de l'essai à blanc sontréécrits à l'identique.
L'essai à blanc gagne ce qui manquait
Un faux
curltient la place de la forge et note chaque appel. On vérifie donc,sans réseau et sans créer d'issue :
n'ouvre rien.
Deux défauts trouvés en chemin, réparés ici
Le pas
shellcheckde la CI ne servait à rien. L'outil n'est pas installé surl'exécutant, donc l'étape était sautée — et elle aurait échoué :
mainporte septavertissements (cinq
SC2155sur deslocal x="$(…)"qui masquent un code deretour, deux
SC1112sur l'apostrophe typographique, voulue). Corrigés, etdeploy/signalement.shrejoint la liste contrôlée. Le jour où shellcheck estinstallé, le pas juge pour de vrai.
L'essai à blanc échouait pour tout compte autre que
stephane. Le garde-foude la cible « pc » jugeait
/home/stephane— le chemin réel — au lieu de${RACINE_BAC}${MAISON}, celui où la livraison écrit. Le job « Livraison » estdonc rouge depuis la pose chez l'opérateur, et personne ne le voyait. Corrigé, et
l'essai porte maintenant un cas qui verrouille ce garde-fou.
Vérifications
les appels à la forge.
shellcheck -S warningmuet sur les cinq scripts de livraison.bash -npropre sur les quatre scripts touchés.À savoir
jqdevient une dépendance de l'exécutant (pacman -S jq). Elle est notée dansle guide de migration du poste.
`deploy/signalement.py` devient `deploy/signalement.sh` : plus une ligne de Python dans la livraison. `curl` fait les appels, `jq` lit les réponses — exigé au démarrage, plutôt qu'un JSON illisible découvert en route. Le contrat ne bouge pas : mêmes arguments, mêmes messages, mêmes codes de sortie. Les trois appels de `livraison.yml` et les quatre de l'essai à blanc sont réécrits à l'identique. L'essai gagne ce qui manquait : un faux `curl` tient la place de la forge et note chaque appel. On vérifie donc l'ouverture de l'issue, le téléversement de la capture, le commentaire, la fermeture au succès suivant, et le refus quand aucun jeton n'est là — sans réseau, sans créer d'issue. Deux défauts trouvés en chemin, réparés ici : * le pas `shellcheck` de la CI ne servait à rien : l'outil n'est pas installé sur l'exécutant, donc l'étape était sautée — et elle aurait échoué, `main` portant sept avertissements (cinq SC2155, deux SC1112). Corrigés, et `deploy/signalement.sh` rejoint la liste contrôlée ; * l'essai à blanc échouait pour tout compte autre que `stephane` : le garde-fou de la cible « pc » jugeait `/home/stephane`, le chemin réel, au lieu de `${RACINE_BAC}${MAISON}`, celui où la livraison écrit. Le job repartait donc rouge depuis la pose chez l'opérateur. Corrigé, et l'essai porte maintenant un cas qui verrouille ce garde-fou. Vérifié : 52 essais verts (contre 39), shellcheck muet sur les cinq scripts.fusion-auto: pas de fusion, la CI est rouge (Crate pcmirror). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.