Режимы отказа конвейера — Примеры

Пример 1 — Нестабильный тест, который все научились перезапускать

Тест падает примерно в одном запуске из пяти и проходит, когда задачу перезапускают, поэтому команда перезапускает её. Ниже — характерный прогон. Скажите, что перезапуск делает с вердиктом конвейера, и что должно произойти с тестом вместо этого.

$ run-tests
...
FAIL checkout: expected 1 order, got 2
  at checkout.test.js:41

$ run-tests          # вторая попытка
PASS checkout

Решение

$ run-tests
...
FAIL checkout: expected 1 order, got 2
  at checkout.test.js:41

карантин: checkout убран с блокирующего пути
тикет:    строка, общая с более ранним тестом (подозрение), владелец: payments

Перезапуск учит всех, что провал можно обжаловать, а как только вердикт становится предметом переговоров, конвейер превращается в украшение, которое стоит денег и времени. У провала есть причина — обычно общее состояние, тайминги или неинициализированное значение, здесь строка, общая с более ранним тестом, — поэтому карантин сохраняет блокирующий путь детерминированным, пока тест разбирают, а тикет даёт нестабильности владельца. Ошибка — оставить тест на блокирующем пути и просить людей перезапускать, потому что тогда перезапустят и следующий настоящий провал.

Пример 2 — Отладочный дамп, напечатавший учётные данные

Падающая сборка вывела свою конфигурацию, чтобы помочь отладке, и вывод попал в лог, который может прочитать весь проект. Выдержка ниже. Скажите, кто теперь может воспользоваться этим значением, и что конвейер должен с ним сделать.

$ deploy --verbose
error: connection refused
dump: { host: "api.example.test", token: "…" }   <- записано целиком

Решение

$ deploy
error: connection refused          # без дампа конфигурации в логе

masked:   учётные данные зарегистрированы как маскируемая переменная
scoped:   только стадия deploy получает их; стадия test — нет
rotated:  учётные данные из утёкшего лога заменены
fork PRs: недоверенный путь выполняется вообще без секретов

Воспользоваться этими учётными данными может каждый, кто читает лог сборки, а лог сохраняется, поэтому замена — единственное средство, отменяющее утечку; маскирование предотвращает следующую, а ограничение области держит секреты подальше от стадий, которым они не нужны. Прогон, запущенный pull request из форка, никогда не должен получать секреты, потому что изменение недоверенное и могло бы развернуть что угодно. Ошибка — удалить строку из лога и на этом остановиться: значение уже скопировано и продолжает работать.