прилетает запрос на этот урл, успешно проходит авторизация и нгинкс редиректом через 301 перекидывает на внутренний домен с этим урлом

вопрос нахера он это делает?

Криво настроен.

да там настроек то почти нет...

Если хочешь помощи, опиши проблему в деталях.

Какой фреймворк для тестирования? Чем собираешь coverage? Сколько тестов? Чет какая-то странная история

Зависит от кучи параметров, на самом деле - количества тестов, их распределения по времени прогона, частоты изменений в кодовой базе, требований к частоте релизов.
Если те же 8 минут на юнит тесты для команды вполне норм (а это весьма быстро), то можно запускать их на любой коммит. А вот если тесты долго работают, или есть тяжёлые/требующие кучи действий для подготовки окружения, типа интеграционных или e2e тестов, то скорее всего стоит их запускать непосредственно перед релизом, а в коммитах запускать исключительно юнит тесты.
Если у проекта есть требования обеспечивать совместимость с разными версиями зависимостей или версиями фреймворка/языка, то обычно это решается матричной сборкой, когда все необходимые комбинации запускаются в параллель. Если какие-то исключительно редкие или тяжёлые, то как и в случае с другими тяжёлыми тестами их можно прогонять непосредственно перед релизом

Я бы не стал так делать. Разработка существенно замедляется, когда ты не видишь сразу же результат изменений, а уж тем более если тесты на написанном тобой коде падают не после пуша коммита или создания MR, а почему-то ночью.

Особенно бесят open source проекты с такими тестами - ты его клонировал, включил CI, а тесты тупо падает на мастере каждый день, хз почему, но в исходном репозитории все нормально. А это единственные тесты в проекте, и даже после создания PR в основной репозиторий не становится яснее, работают ли твои правки вообще или нет, потому что тесты все так же запускаются по расписанию.

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

Тут нужна культура написания тестов, чтобы проблемных было как можно меньше, чтобы они в целом были более воспроизводимыми и понятными. И конечно же обязательный coverage, чтобы новый код не оставался без тестов ни при каких условиях.

Но это не вопрос CI, как таковой, и уж тем более не относится к куберу. Так что предлагаю уйти оффтопить в другое место

Спасибо! Очень подробно)

Как проснешься расскажешь что ты там начитал :)

И

а могу ли я как то с помощью kubectl получить адрес, на котором расположен ингрес контроллер

либо его надо писать руками в какую нибудь переменную и оттуда читать

кроме kubectl describe services my-service

kubectl get svc my-service -n namespace -owide

ты это имел ввиду?

kubectl get ingress -o wide и посомтреть туда

зачем в svc смотрет? У тебя на нее может смотреть 100500 контроллеров