CI не должна зависеть от одного package registry

Симптом

CI начала падать на этапе сборки образов из-за таймаутов при подключении к pypi.org.

Контекст

Сборка зависела от доступности внешнего package registry. Когда соединение стало недоступно из среды сборки, код и Dockerfile не менялись, но новые образы перестали собираться.

Корневая причина

Один внешний registry был единственным источником Python-пакетов для CI. Причина недоступности могла находиться в сетевом контуре или на маршруте до registry, но архитектурно результат был одинаковым: критичный pipeline зависел от одной внешней точки.

Ошибочное предположение

Мы считали публичный package registry настолько базовой частью экосистемы, что его доступность можно не закладывать в дизайн доставки. Внешняя популярность сервиса не делает конкретный сетевой маршрут или endpoint гарантированно доступным.

Обнаружение

Проблему обнаруживал сам pipeline по повторяющимся timeout при установке зависимостей. Нужен отдельный монитор доступности registry из того же сетевого контура, где запускается CI, а не только проверка из рабочей станции.

Исправление

В качестве основного источника подключили зеркало PyPI. Для production workflow также были определены резервный mirror и собственный proxy/cache, которые сохраняют необходимые версии пакетов и не зависят от одного внешнего маршрута.

Проверка

Сборка должна проверяться из CI-среды при:

• штатном registry;
• недоступном основном registry;
• переключении на резервный источник;
• наличии пакетов только в локальном cache или proxy.

Нужно также проверять воспроизводимость по lock-файлу и наличие всех требуемых артефактов в резервном источнике.

Общий вывод

Внешние package registries - часть цепочки поставки, а не абстрактно надёжный фон. Для критичного CI нужны зеркала, cache или собственный proxy и регулярно проверяемый план переключения.