Simuler un mauvais réseau en CI
La fenêtre est facultative. Le même exécutable fonctionne comme outil en ligne de commande, se termine tout seul après une durée donnée et rend compte de ce qui s’est passé d’une manière qu’un pipeline sait lire.
La forme d’une étape
Dégradez pendant la durée du test, puis laissez l’outil s’arrêter tout seul. Aucune étape de nettoyage à oublier :
BeanNetworkTester.exe --loss 10 --latency 200 --target myapp.exe --duration 60Dans un job GitHub Actions, sur un runner Windows auto-hébergé :
- name: Test the app on a poor connection
shell: pwsh
run: |
Start-Process -FilePath BeanNetworkTester.exe `
-ArgumentList '--loss 10 --latency 200 --target myapp.exe --duration 90'
npm testDeux choses à propos du runner : la capture du trafic exige des droits d’administrateur, et un runner hébergé ne vous les donnera pas, donc cela a sa place sur une machine Windows auto-hébergée.
Chaque fin a un code de sortie
Rien ne se termine par une trace d’appels. Chaque façon dont une exécution peut finir a un numéro, si bien qu’un pipeline peut distinguer « votre application a échoué » de « l’outil n’a pas pu démarrer » :
| Code | Signification |
|---|---|
| 0 | Terminé comme demandé. |
| 1 | Une erreur est survenue pendant l’exécution. |
| 2 | La ligne de commande était incorrecte. |
| 3 | Un réglage ou une valeur était invalide. |
| 4 | Un fichier de scénario a été rejeté. |
| 5 | Un fichier n’a pas pu être lu ou écrit. |
| 6 | Une assertion sur l’exécution ne s’est pas vérifiée. |
| 7 | Pas de droits d’administrateur : le pilote ne peut pas se charger. |
| 130 | Interrompu, généralement par Ctrl+C. |
| 143 | Arrêté de l’extérieur. |
Sortie lisible par une machine
--format json écrit un objet JSON par ligne, des échantillons pendant l’exécution et un récapitulatif à la fin, afin qu’une étape ultérieure puisse faire des assertions dessus :
BeanNetworkTester.exe --loss 5 --duration 30 --format json > run.ndjsonLes lignes de journal vont sur l’erreur standard et les données sur la sortie standard, si bien que rediriger les données ne mélange jamais les deux. --seed rend l’exécution répétable, ce dont un test instable a besoin avant que quiconque puisse en discuter.
Un essai à blanc qui ne touche à rien
Deux options permettent de l’intégrer sans risque avant de lui faire confiance : --dry-run indique ce que feraient les réglages puis se termine, et --simulate fait tourner tout le moteur sur du trafic synthétique, sans charger le pilote et sans toucher au réseau. Les deux sont utiles dans une build qui ne doit pas dégrader la machine sur laquelle elle tourne.