После timeout не сохранился отчёт: резервируем время GitLab Runner

Долгий тест превысил timeout job. После него должен был выполниться after_script, собрать диагностические файлы и передать artifacts, но нужного архива нет. Команда сбора выглядит корректно. Проблема может быть не в ней: весь доступный срок уже потрачен основной частью задания, и на заключительные действия времени не осталось.

У задания есть общий бюджет, а у script и after_script могут быть собственные ограничения. Эти сроки нужно согласовать. Если основной скрипт имеет право занять всё окно job, нельзя одновременно рассчитывать на гарантированное дополнительное время после него. Планирование здесь такое же, как у HTTP-запроса с несколькими зависимостями: внутренние операции должны завершаться раньше внешнего дедлайна.

Оставить запас на заключительные действия

Начиная с Runner 16.4, длительности script и after_script можно задавать соответствующими переменными. Пример оставляет основному действию восемь минут из десяти, заключительному — минуту, а остаток нужен подготовке и передаче файлов.

tests:
  timeout: 10m
  variables:
    RUNNER_SCRIPT_TIMEOUT: 8m
    RUNNER_AFTER_SCRIPT_TIMEOUT: 1m
  script:
    - ./run-tests.sh
  after_script:
    - ./collect-report.sh
  artifacts:
    when: always
    paths:
      - reports/

Оба скрипта здесь — файлы вашего проекта, а reports должен реально создаваться командой. when: always задаёт политику выгрузки при допустимом ходе завершения задания, но не создаёт бесконечное время и не восстанавливает потерянный runner. Отчёт лучше писать постепенно во время работы, чтобы after_script только собрал уже существующие файлы.

Учтите ограничение runner на максимальную длительность job. Значение в YAML не отменяет более строгую внешнюю настройку. Полезно выписать реальные границы рядом: общий timeout, лимит script, лимит after_script и приблизительное время выгрузки архива. Для тяжёлого отчёта последняя часть может оказаться существенной.

Проверить именно прерывание

Сначала запустите короткий успешный тест и убедитесь, что reports появляется в artifacts. Затем на отдельной диагностической ветке заставьте основной скрипт превысить свой внутренний лимит раньше общего. В журнале должны быть видны прерывание script, запуск after_script и загрузка файлов. Проверять только зелёный pipeline недостаточно: проблема проявляется на другой траектории завершения.

Пусть сборщик завершает работу быстро и не зависит от зависшего тестового процесса. Например, он может копировать уже записанный журнал и формировать короткий индекс, вместо повторного обращения к недоступному сервису. Если сборщик сам делает сеть без ограничений, запас времени снова будет израсходован непредсказуемо.

После настройки красный тест должен оставаться красным, а диагностический пакет — помогать понять причину. Отдельно проверяйте статус и наличие файлов: успешная выгрузка не делает тест успешным, а ошибка теста не должна автоматически лишать команду всей информации о запуске.

Продолжить практику

Исправление одной job полезно закрепить в полном процессе выпуска. В программе курса «GitLab CI/CD: автоматизация сборки и деплоя» — pipeline учебного приложения с проверками, тестами, сборкой Docker-образа, registry и staging. Отдельно разбираются runners, секреты, нестабильные запуски и возврат к предыдущему образу. Такой проект помогает увидеть, как решение внутри одной job влияет на выпуск версии и дальнейший откат.

Посмотреть программу курса

Источник: официальная документация.

Другие задачи по теме: Окружение задания и повторяемый pipeline.