Какие задачи выполняли в GitLab?

Что проверяют

Понимаете ли вы, как Go-сервис проходит путь от коммита до прода, и можете ли сами поправить пайплайн, а не только ждать DevOps. Интервьюеру важна конкретика: что проверяется на каждом MR и как собирается образ. Типичное уточнение: «Почему у вас долго шла сборка и что вы с этим сделали?»

Как отвечать

Опишите пайплайн своего сервиса по стадиям и отметьте, что настраивали лично:

• проверки: go vet и golangci-lint, go test -race с покрытием, отчёт через gotestsum в формате JUnit, чтобы упавшие тесты были видны прямо в MR;
• кеш: модули и кеш сборки через GOMODCACHE и GOCACHE, вынесенные внутрь $CI_PROJECT_DIR, потому что кеш GitLab сохраняет только пути внутри каталога проекта;
• сборка образа: многоэтапный Dockerfile, где на первом этапе собирается бинарник с CGO_ENABLED=0, а в итоговый образ попадает только он; сборка через Docker-in-Docker или buildah, публикация в GitLab Container Registry;
• деплой: окружения через environment, ручное подтверждение when: manual для прода, Helm или манифесты Kubernetes;
• правила запуска: rules для разных веток и MR, needs для параллельных джоб, защищённые ветки и переменные;
• приватные модули: GOPRIVATE и доступ к соседним репозиториям через CI_JOB_TOKEN.

Кроме CI, в GitLab обычно есть Merge Request с ревью и обязательным зелёным пайплайном перед мержем. Цифры приводите реальные: сборка шла 12 минут, после кеша модулей и распараллеливания тестов стала идти 4. Если пайплайн писали не вы, скажите, какие изменения вносили сами, и честно обозначьте границу.

Где спотыкаются

Указывают в кеше /go/pkg/mod и удивляются, что он не сохраняется между джобами. Пути вне каталога проекта GitLab не кеширует.

Хранят токены и пароли прямо в .gitlab-ci.yml. Для этого есть маскированные и защищённые CI/CD-переменные.

Говорят «ускорил сборку на 30%» и не могут объяснить, за счёт чего. Интервьюера интересует механизм: кеш, параллельность, меньший образ.