Всем привет! Решила поделиться свежим кейсом из практики. На днях мы внедряли новый пайплайн в GitLab CI для автотестов на Python. Всё шло гладко, пока я не заметила, что некоторые тесты падают только на этапе merge request, а локально проходят. Оказалось, проблема была не в тестах, а в конфигурации окружения: переменные окружения передавались не все, и один модуль крашился без них. В итоге я перерыла весь пайплайн и нашла ещё пару скрытых багов в самом коде, которые не проявлялись в dev-среде.
Кто сталкивался с подобным? Как вы отлавливаете баги, связанные с CI/CD, а не с логикой приложения? Делитесь своими историями — может, у кого-то есть лайфхаки по настройке пайплайнов для автотестов. Я всегда за порядок в коде и инфраструктуре!
💡 1
О, Лена, привет! Твой кейс — классика CI/CD-джунглей, я такие же грабли собирала пару месяцев назад. У нас был похожий цирк: тесты на Selenium падали в пайплайне, но локально — идеально. Перерыла логи, докерфайлы — оказалось, в контейнере не стоял chromedriver нужной версии, а в dev-окружении он был глобально. Плюс один тест крашился из-за race condition при параллельном запуске в GitLab — локально я гоняла последовательно и не замечала.
Теперь у нас железное правило: для CI/CD мы выносим все конфиги в отдельную папку `.ci/` и пишем маленький smoke-тест, который проверяет окружение перед основной пачкой — типа, есть ли переменные, верные ли версии зависимостей. Ещё я добавила в пайплайн шаг с `pytest --co` для быстрой проверки синтаксиса и импортов, чтобы отсекать очевидные косяки до прогона. А для отлова багов, связанных с инфраструктурой, мы логируем все ENV-переменные в начале джобы (без секретов, конечно) — это спасло уже раза три. Как ты решаешь проблему с неполной передачей переменных? Просто через `variables` в `.gitlab-ci.yml` или используешь Vault/секреты с fallback-значениями в коде?
Ну давай разберем. Тут классическая история: CI/CD не прощает халтуры с окружением, а Selenium — вообще отдельный вид шаманства. Твой кейс про race condition при параллельном запуске — боль знакомая. Я бы добавил к твоему smoke-тесту еще и проверку на сериализацию тестов, если они не thread-safe: либо забить в `pytest -n 1` на старте, либо явно разложить по очередям в GitLab через `parallel:matrix` с разными наборами тегов. С переменными окружения — да, `variables` в `.gitlab-ci.yml` рулит, но я еще загоняю обязательные переменные в `before_script` с явным `fail` через shell-проверку, чтобы не гадать, почему тест упал из-за пустого `API_KEY`. Vault — это хорошо, но для мелких проектов оверхед, проще сделать fallback-значения в коде с лог-варнингом, чтобы не плодить магию.
👎 1
