Symulacja słabej sieci w CI

Okno jest opcjonalne. Ten sam plik wykonywalny działa jako narzędzie linii komend, kończy się sam po zadanym czasie i raportuje wynik w formie, którą pipeline umie przeczytać.

Kształt kroku

Psuj sieć na czas testu i pozwól narzędziu zatrzymać się samo. Nie ma kroku sprzątającego, o którym można zapomnieć:

BeanNetworkTester.exe --loss 10 --latency 200 --target myapp.exe --duration 60

W zadaniu GitHub Actions, na własnym runnerze z Windows:

- name: Test aplikacji na słabym łączu
  shell: pwsh
  run: |
    Start-Process -FilePath BeanNetworkTester.exe `
      -ArgumentList '--loss 10 --latency 200 --target myapp.exe --duration 90'
    npm test

Dwie rzeczy o runnerze: przechwytywanie ruchu wymaga praw administratora, a runner hostowany przez GitHuba ich nie da, więc to zadanie należy do własnej maszyny z Windows.

Każde zakończenie ma kod wyjścia

Nic nie kończy się tracebackiem. Każdy sposób zakończenia przebiegu ma numer, więc pipeline rozróżni "Twoja aplikacja padła" od "narzędzie nie mogło wystartować":

Kod	Co znaczy
0	Skończyło się tak, jak zamówiono.
1	Coś padło w trakcie działania.
2	Błąd w linii komend.
3	Nieprawidłowe ustawienie albo wartość.
4	Plik scenariusza został odrzucony.
5	Nie udało się odczytać albo zapisać pliku.
6	Założenie o przebiegu się nie potwierdziło.
7	Brak praw administratora, więc sterownik się nie wczyta.
130	Przerwane, zwykle przez Ctrl+C.
143	Zakończone z zewnątrz.

Wyjście do czytania maszyną

--format json wypisuje jeden obiekt JSON na linię - próbki w trakcie przebiegu, podsumowanie na końcu - więc kolejny krok może na tym asertować:

BeanNetworkTester.exe --loss 5 --duration 30 --format json > run.ndjson

Linie logu idą na standardowe wyjście błędu, a dane na standardowe wyjście, więc przekierowanie danych nigdy nie miesza jednego z drugim. --seed czyni przebieg powtarzalnym, a tego potrzebuje niestabilny test, zanim ktokolwiek zacznie się o niego spierać.

Przebieg na próbę, który niczego nie rusza

Dwie flagi pozwalają wpiąć to, zanim zaczniesz temu ufać: --dry-run mówi, co zrobiłyby ustawienia, i kończy pracę, a --simulate uruchamia cały silnik na sztucznym ruchu, bez wczytywania sterownika i bez dotykania sieci. Obie są przydatne w buildzie, który nie może zepsuć maszyny, na której chodzi.

Dalej

Chcesz zepsuć sobie sieć specjalnie?

Pobierz na Windows