Как создавать монорепозитории Nx в Gitlab CI Runner
Я пытаюсь создать CI gitlab, который выполняет следующие действия:
- Установите зависимости пряжи и кэшируйте их, чтобы не приходилось устанавливать пряжу в каждом задании.
- Протестируйте все мои модифицированные приложения с помощью команды
nx affected - Соберите все мои модифицированные приложения с помощью команды
nx affected - Создайте мои образы докеров с моими модифицированными приложениями
Я пробовал много способов сделать это в своем CI, и ни один из них не работал. Я очень застрял на самом деле.
Это мой фактический CI:
default:
image: registry.gitlab.com/xxxx/xxxx/xxxx
stages:
- setup
- test
- build
- forge
.distributed:
interruptible: true
only:
- main
- develop
cache:
key:
files:
- yarn.lock
paths:
- node_modules
- .yarn
before_script:
- yarn install --cache-folder .yarn-cache --immutable --immutable-cache --check-cache
- NX_HEAD=$CI_COMMIT_SHA
- NX_BASE=${CI_MERGE_REQUEST_DIFF_BASE_SHA:-$CI_COMMIT_BEFORE_SHA}
artifacts:
paths:
- node_modules
test:
stage: test
extends: .distributed
script:
- yarn nx affected --base=$NX_BASE --head=$NX_HEAD --target=test --parallel=3 --ci --code-coverage
build:
stage: build
extends: .distributed
script:
- yarn nx affected --base=$NX_BASE --head=$NX_HEAD --target=build --parallel=3
forge-docker-landing-staging:
stage: forge
services:
- docker:20.10.16-dind
rules:
- if: $CI_COMMIT_BRANCH == "develop"
allow_failure: true
- exists:
- "dist/apps/landing/*"
allow_failure: true
script:
- docker build -f Dockerfile.landing -t landing:staging .
В настоящее время вот что работает, а что нет:
- ❌ Кэширование не работает, выполняется установка пряжи во всех полученных заданиях
extends: .distributed - ✅ Затронутые команды Nx работают должным образом (тестирование и сборка)
- ❌ Сборка приложений с помощью докера не работает, у меня проблемы с докером в докере.
@Benjamin Я использовал средство запуска докеров и следовал этому руководству: docs.gitlab.com/ee/ci/docker/using_docker_build.html
Ответы 1
Проблема № 1: вы не кэшируете свой каталог .yarn-cache, в то время как вы явно указываете его в разделе yarn install in before_script. Итак, решение простое — добавьте .yarn-cache в раздел cache.paths.
Касательно
он выполняет установку пряжи во всех заданиях, которые получили расширения: .distributed
Это предполагаемое поведение в вашем конвейере, поскольку «расширяет» в основном объединяет разделы вашей конфигурации gitlab-ci, поэтому на этапе тестирования в основном используется следующий сценарий bash в образе бегуна:
yarn install --cache-folder .yarn-cache --immutable --immutable-cache --check-cache
NX_HEAD=$CI_COMMIT_SHA
NX_BASE=${CI_MERGE_REQUEST_DIFF_BASE_SHA:-$CI_COMMIT_BEFORE_SHA}
yarn nx affected --base=$NX_BASE --head=$NX_HEAD --target=test --parallel=3 --ci --code-coverage
и этап сборки отличается только одной последней строкой
Когда вы кешируете папку сборки - фаза установки будет намного быстрее.
Также в этом случае
artifacts:
paths:
- node_modules
не нужен, так как он придет из кеша. Удаление его из артефактов также уменьшит нагрузку на ваш экземпляр gitlab, node_modules обычно огромен и не имеет смысла в качестве артефакта.
Проблема № 2: Какой у вас артефакт?
Вы не предоставили свой файл докеров или какую-либо подсказку о том, что именно создается на ваших этапах сборки, поэтому я предполагаю, что ваш этап build создает что-то в каталоге dist. Если вы хотите использовать это на этапе сборки докера - вы должны указать это в разделе artifacts вашего задания build:
build:
stage: build
extends: .distributed
script:
- yarn nx affected --base=$NX_BASE --head=$NX_HEAD --target=build --parallel=3
artifacts:
paths:
- dist
После этого ваша работа forge-docker-landing-staging получит доступ к вашим артефактам сборки.
Проблема №3: Docker не работает!
Без каких-либо журналов из вашей системы CI невозможно помочь вам, а также нарушает политику SO «один вопрос на вопрос». Если другие ваши этапы работают нормально — рассмотрите возможность использования kaniko вместо докера в докере, поскольку использование DinD на самом деле является кошмаром безопасности (вы фактически даете права root на своей машине сборки любому, кто может редактировать файл .gitlab-ci.yml) . См. https://docs.gitlab.com/ee/ci/docker/using_kaniko.html, и в вашем случае должно работать что-то вроде задания ниже (не проверено):
forge-docker-landing-staging:
stage: forge
image:
name: gcr.io/kaniko-project/executor:v1.9.0-debug
entrypoint: [""]
rules:
- if: $CI_COMMIT_BRANCH == "develop"
allow_failure: true
- exists:
- "dist/apps/landing/*"
allow_failure: true
script:
- /kaniko/executor
--context "${CI_PROJECT_DIR}"
--dockerfile "${CI_PROJECT_DIR}/Dockerfile.landing"
--destination "${CI_REGISTRY_IMAGE}:landing:staging"
Какой бегун вы используете? (например, автомасштабирование докер-машины, k8s, докер, оболочка и т. д.)