Gitlab CI при развертывании Docker-in-Docker не выполняет команды внутри контейнера - PullRequest
Новая
       8

Gitlab CI при развертывании Docker-in-Docker не выполняет команды внутри контейнера

0 голосов
/ 26 ноября 2018

Я пытаюсь настроить новый конвейер сборки для одного из наших проектов.На первом этапе я создаю новый образ докера для последовательного тестирования.Этот шаг работает отлично.Однако при выполнении тестовых заданий образ извлекается, но команды выполняются на хосте, а не на контейнере.

Вот содержимое моего gitlab-ci.yml: 

stages:
  - build
  - analytics

variables:  
  TEST_IMAGE_NAME: 'registry.server.de/testimage'

build_testing_container:
  stage: build

  image: docker:stable
  services:
  - dind

  script:
    - docker build --target=testing -t $TEST_IMAGE_NAME .
    - docker push $TEST_IMAGE_NAME

mess_detection:
  stage: analytics
  image: $TEST_IMAGE_NAME

  script:
    - vendor/bin/phpmd app html tests/md.xml --reportfile mess_detection.html --suffixes php

  artifacts:
    name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}"
    paths:
      - mess_detection.html
    expire_in: 1 week
    when: always

  except:
    - production

  allow_failure: true

Что мне нужно изменить, чтобы gitlab runner выполнял команды script внутри контейнера, который он успешно извлекает?

ОБНОВЛЕНИЕ:

Это становится еще интереснее:Я просто изменил сценарий на некоторое время, чтобы я мог присоединиться к контейнеру.Когда я запускаю pwd из скрипта ci, он говорит /builds/namespace/project.Однако при запуске pwd на сервере с docker exec с использованием точно такого же контейнера возвращается /app, как и положено.

UPDATE2:

После еще одного исследования я узнал, что gitlab выполняет четыре подэтапа для каждого шага сборки:

После некоторого дополнительного исследования я обнаружил, что gitlab выполняет 4 подэтапа для каждого шага сборки:

  1. Подготовка : создание и запуск служб.
  2. Предварительная сборка : клонирование, восстановление кэша и загрузка артефактов из предыдущих этапов.Это выполняется на специальном образе Docker.
  3. Build : сборка пользователя.Он запускается на предоставленном пользователем образе докера.
  4. Пост-сборка : создание кэша, загрузка артефактов в GitLab.Это выполняется на специальном образе Docker.

Похоже, что в моем случае шаг 3 не выполняется должным образом, и команда все еще выполняется в образе докера gitlab runner.

UPDATE3 Тем временем я тестировал выполнение шага mess_detection на отдельной машине с помощью команды gitlab-runner exec docker mess_detection.Поведение точно такое же.Так что это не специфично для gitlab, но должно быть некоторым параметром конфигурации в сценарии развертывания или в конфигурации бегуна.

...