К сожалению это ограничение исходит от retrofit. А точнее от okhttp3.Response.isSuccessful().
Я рассматривал вариант изменения диапазона успешных/ошибочных статусов. Но решил пока не вклиниваться в базовую работу клиента.
При настройке клиента new OkHttpClient.Builder().followRedirects(true).followSslRedirects(true) ошибок не возникает и клиент сам следует по редиректам без нашего участия.
Но так или иначе это дело нужно продумать и доработать.
trap к сожалению не работает для отмененных задач. На сколько я понял, при отмене задачи терминальная сессия убивается с SIGKILL вместе с исполняемыми в данной сессии процессами. Т.е. trap как процесс тоже убивается. Но штука определенно классная.
Решение выше предложил 411.
trap “<муваем логи в отдельную папочку>” ERR
make test
В этом случе, если make test завершится с ошибкой, то сработает перемещение логов в специальную папку, а дальше их уже собрать как артефакты. Если же все хорошо, то в логах пайплайна будет предупреждение, что артефакты не найдены.
Коммитов могло быть много, а пушей в репу вот не сильно много было. Чтоб 100 гигов за день, такого не помню.
В моей практике мы делали максимально удобно для локального запуска окружения/тестов. Разработчики прежде чем пушить гоняли тесты у себя локально. Но тут повторюсь все должно быть максимально удобно. И собрать и тесты прогнать (быстро), и в случае ошибок максимально информативные логи посмотреть. Как оказалось, разработчику проще локально все прогнать и чуть-что логи грепнуть, чем по ссылкам GitLab маневрировать.
Все верно.
Задача по расписанию на очистку раннера настроена на 5 утра. В 5 утра крайне низкая вероятность, что кто-то будет что-то пушить.
Но, если возникла необходимость почистить стенд прямо сейчас, то да. Все запущенные контейнеры будут остановлены и выполняемые задачи с интеграционными тестами упадут. Но предполагается, что запускающий понимает последствия.
Еще момент. Для очистки стенда, фильтрация по CI_JOB_ID и не предполагается. Мы же раннер чистим в принципе, а не от «ошметков» какой-либо конкретной задачи.
okhttp3.Response.isSuccessful().Я рассматривал вариант изменения диапазона успешных/ошибочных статусов. Но решил пока не вклиниваться в базовую работу клиента.
При настройке клиента
new OkHttpClient.Builder().followRedirects(true).followSslRedirects(true)ошибок не возникает и клиент сам следует по редиректам без нашего участия.Но так или иначе это дело нужно продумать и доработать.
Решение выше предложил 411.
trap “<муваем логи в отдельную папочку>” ERR
make test
В этом случе, если make test завершится с ошибкой, то сработает перемещение логов в специальную папку, а дальше их уже собрать как артефакты. Если же все хорошо, то в логах пайплайна будет предупреждение, что артефакты не найдены.
В моей практике мы делали максимально удобно для локального запуска окружения/тестов. Разработчики прежде чем пушить гоняли тесты у себя локально. Но тут повторюсь все должно быть максимально удобно. И собрать и тесты прогнать (быстро), и в случае ошибок максимально информативные логи посмотреть. Как оказалось, разработчику проще локально все прогнать и чуть-что логи грепнуть, чем по ссылкам GitLab маневрировать.
Задача по расписанию на очистку раннера настроена на 5 утра. В 5 утра крайне низкая вероятность, что кто-то будет что-то пушить.
Но, если возникла необходимость почистить стенд прямо сейчас, то да. Все запущенные контейнеры будут остановлены и выполняемые задачи с интеграционными тестами упадут. Но предполагается, что запускающий понимает последствия.
Еще момент. Для очистки стенда, фильтрация по CI_JOB_ID и не предполагается. Мы же раннер чистим в принципе, а не от «ошметков» какой-либо конкретной задачи.