GitFlic с CI/CD и container registry: переводим ещё один проект с GitHub

Примерно полгода назад мы перевели первый клиентский проект на GitFlic и написали об этом вскользь - тогда платформа закрывала минимум: репозитории, code review, базовый merge request. CI/CD там был только в планах, container registry отсутствовал. С GitHub Actions пайплайны оставляли жить на месте, а GitFlic использовали как зеркало с красивым отечественным адресом.

Теперь GitFlic запустил CI/CD и собственный container registry. Мы взяли реальный проект - один из сервисов клиента из сектора, которому важна отечественная цепочка поставки - и прошли полный путь переноса. Вот что из этого вышло.

Что именно появилось

CI/CD. GitFlic запустил собственный runner на базе Docker и синтаксис пайплайнов, близкий к GitLab CI. Конфигурация идёт через файл .gitflic-ci.yml в корне репозитория. Stages, jobs, artifacts, условия по веткам - базовый набор присутствует.

Container registry. Встроенный реестр образов доступен по адресу вида registry.gitflic.ru/<org>/<project>. Docker push/pull работает через стандартный токен авторизации. Для проектов, которые собирают образы и хотят хранить их в той же цепочке - это закрывает важный пробел.

Адаптация пайплайнов: что прошло гладко

Синтаксис .gitflic-ci.yml действительно похож на GitLab CI - если писали пайплайны там, стартовый порог минимальный. Stages, переменные окружения, условия only/except по веткам работают ожидаемо. Базовый пайплайн «собрать Docker-образ, прогнать тесты, запушить в registry» занял около часа на перенос с GitHub Actions.

Секреты организованы нормально - через переменные в настройках проекта, доступны в джобах как переменные окружения. Для регистрации в собственном container registry пришлось добавить два секрета (GITFLIC_REGISTRY_USER, GITFLIC_REGISTRY_TOKEN) и подправить docker login в скриптах.

Где пришлось поработать

Actions-специфичные шаги. GitHub Actions имеет огромный маркетплейс готовых action-ов: actions/checkout, docker/build-push-action, google-github-actions/... и сотни других. В GitFlic ничего этого нет - только чистые shell-команды в блоке script. Это не катастрофа, но каждый такой action нужно разворачивать в bash-команды вручную. На нашем пайплайне таких шагов нашлось семь штук - часть заменилась тривиально, часть потребовала написать небольшие скрипты.

Скорость runner'ов. Это самый заметный момент. На GitHub Actions hosted runner - это быстрые машины с хорошим интернетом и кешированием зависимостей между джобами. GitFlic runner работает медленнее: pull образов занимает дольше, сборка образов без layer cache ощутимо медленнее. Наш пайплайн с ~8 минут на GitHub Actions вырос до ~18 минут на GitFlic при первых прогонах.

После того как добавили явное кеширование слоёв через DOCKER_BUILDKIT=1 и настроили BuildKit cache mount для зависимостей - вернулись к ~12 минутам. Не паритет, но терпимо для задач, где скорость сборки не критична.

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

Container registry в работе

Registry подключился к docker push без сюрпризов. Образы хранятся, тегирование по коммиту и веткам работает как ожидается. Команды docker pull registry.gitflic.ru/... из тестовой среды клиента - без проблем.

Один нюанс: retention policy (автоудаление старых тегов) на момент нашего теста либо не работал, либо мы не нашли где его настраивать. Место в registry накапливается, если не чистить теги вручную или через скрипт в пайплайне. Добавили джоб с docker manifest + curl в API для очистки образов старше 30 дней - пока так.

Итог по переносу

Цепочка поставки теперь полностью в российской юрисдикции: код, CI/CD, образы - всё в GitFlic. Для клиентов, которым это важно по организационным или регуляторным причинам, это реальный аргумент. Платформа дошла до состояния, где можно строить на ней полноценный DevOps-процесс, а не только хранить код.

Честный минус: GitFlic не GitHub с многолетней экосистемой интеграций. Там, где GitHub Actions закрывает задачу готовым блоком, здесь надо писать скрипты. Это нормальная цена молодой платформы - но надо понимать, что несколько дополнительных дней на адаптацию пайплайнов стоит закладывать.

Клиентов, которых сопровождаем в рамках managed-услуги, переводим постепенно: сначала те, кому отечественная цепочка поставки принципиальна по требованиям, остальные - по мере созревания экосистемы.