Получение GitLab CI для клонирования частных репозиториев

Я публикую это как ответ, так как другие не были полностью ясны и / или подробны ИМХО.

Начиная с GitLab 8.12+, предполагая, что репозиторий подмодуля находится на том же сервере, что и тот, который его запрашивал, теперь вы можете:

1. Настройте репо с помощью подмодулей git как обычно (git submodule add git@somewhere:folder/mysubmodule.git)

2. Измените свой .gitmodules файл следующим образом

    [submodule "mysubmodule"]
      path = mysubmodule
      url = ../../group/mysubmodule.git
   

   где ../../group/mysubmodule.git - относительный путь от вашего репозитория до подмодуля.

3. Добавьте следующие строки в gitlab-ci.yml

    variables:
      GIT_SUBMODULE_STRATEGY: recursive
   

   чтобы исполнитель получил все подмодули до сборки.

Предостережение: если ваш бегун игнорирует директиву GIT_SUBMODULE_STRATEGY, вам, вероятно, следует подумать о обновить его.

(источник: https://docs.gitlab.com/ce/ci/git_submodules.html)

Смотрите также другие решения:

• разрешение подмодуля git (см. ответ Марко А.)
• токен задания и переопределить репо в конфигурации git (см. ответ a544jh)

Вот полное руководство с ключами SSH:

Общий дизайн

• создание пары ключей SSH
• добавление частного в качестве безопасной переменной среды вашего проекта
• сделать частный доступным для ваших тестовых скриптов на GitLab-CI
• добавление общедоступного в качестве ключа развертывания для каждой из ваших частных зависимостей

Генерация пары публичных и приватных ключей SSH

Сгенерируйте пару публичных и приватных ключей SSH без парольной фразы:

ssh-keygen -b 4096 -C "<name of your project>" -N "" -f /tmp/name_of_your_project.key

Добавление закрытого SSH-ключа в ваш проект

Вам необходимо добавить ключ как безопасную переменную среды в свой проект следующим образом:

• просмотреть https://<gitlab_host>/<group>/<project_name>/variables
• нажмите "Добавить переменную"
• заполните текстовое поле Key SSH_PRIVATE_KEY
• заполните текстовое поле Value самим закрытым ключом SSH
• нажмите "Сохранить изменения"

Предоставление закрытого SSH-ключа вашим тестовым скриптам

Чтобы сделать ваш закрытый ключ доступным для ваших тестовых сценариев, вам необходимо добавить следующее в ваш .gitlab-ci.yml файл:

before_script:
  # install ssh-agent
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  # run ssh-agent
  - eval $(ssh-agent -s)
  # add ssh key stored in SSH_PRIVATE_KEY variable to the agent store
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  # disable host key checking (NOTE: makes you susceptible to man-in-the-middle attacks)
  # WARNING: use only in docker container, if you use it with shell you will overwrite your user's ssh config
  - mkdir -p ~/.ssh
  - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config

Фрагмент кода взят из документации GitLab

Если вы не хотите возиться с ключами или подмодулями ssh, вы можете переопределить репо в конфигурации git для аутентификации с помощью токена задания (в gitlab-ci.yml):

before_script:
  - git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/group/repo.git".insteadOf [email protected]:group/repo.git

принятый в настоящее время ответ включает требования, специфичные для Gitlab, в мой .gitmodules файл. Это заставляет конкретную структуру каталогов для локальной разработки и усложняет переход на другую платформу управления версиями.

Вместо этого я последовал совету из ответа Juddling. Вот более полный ответ.

Мои .gitmodules файлы имеют следующее содержимое:

[submodule "myproject"]
    url = [email protected]:mygroup/myproject.git

В моем gitlab-ci.yml есть следующее:

build:
  stage: build
  before_script:
    - git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@git.myhost.com/".insteadOf "[email protected]:"
    - git submodule sync && git submodule update --init

Завершающие / и : критичны в строке git config, поскольку мы сопоставляем аутентификацию SSH с HTTPS. Это на время сбило меня с толку с ошибкой «Недопустимый номер порта».

Мне нравится это решение, потому что оно включает специфичные для Gitlab требования в специфический для Gitlab файл, который игнорируется всем остальным.

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

git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git

Токены развертывания предназначены для каждого проекта и доступны только для чтения.

У меня был сценарий, в котором мне приходилось использовать свой ssh-ключ в 3 разных сценариях, поэтому я поместил материал ssh-ключа в один сценарий оболочки и вызвал его первым, прежде чем остальные 3 сценария. В итоге это не сработало, я думаю, из-за того, что ssh-agent не сохраняется между сценариями оболочки или что-то в этом роде. В итоге я просто вывел закрытый ключ в файл ~/.ssh/id_rsa, который наверняка сохранится в других сценариях.

.gitlab-ci.yml

script:
    - ci/init_ssh.sh
    - git push # or whatever you need ssh for

ci / init_ssh.sh

# only run in docker:
[[ ! -e /.dockerenv ]] && exit 0

mkdir -p ~/.ssh
echo "$GITLAB_RUNNER_SSH_KEY" > ~/.ssh/id_rsa
chmod 400 ~/.ssh/id_rsa
echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > /.ssh/config

Работает как часы!

Один из способов решить эту проблему без изменения структуры репозитория git - выполнить следующие шаги:

1. получить ключи хоста ssh

Получите ключи хоста ssh для сервера, на котором вы работаете. Для gitlab.com:

1. запустить ssh-keyscan gitlab.com > known_hosts
2. убедитесь, что ssh-keygen -lf known_hosts соответствует отпечаткам пальцев, указанным здесь .
3. скопируйте содержимое known_hosts и вставьте его в переменную с именем SSH_KNOWN_HOSTS в репозитории.

Этот шаг нужен только один раз.

2. настроить задание на использование ssh

before_script:
    - git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com".insteadOf "[email protected]:"
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts

Бит "ssh://[email protected]" может быть другим, если вы пытаетесь выполнить git clone [email protected]: или pip install -e git+ssh://[email protected]/...; отрегулируйте его в соответствии с вашими потребностями.

На этом этапе ваш CI может использовать ssh для выборки из другого (частного) репозитория.

3. [Bonus DRY]

Используйте этот трюк, чтобы написать его в общем виде:

.enable_ssh: &enable_ssh |-
    git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com".insteadOf "ssh://[email protected]"
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
    chmod 644 ~/.ssh/known_hosts

и включите его на тех вакансиях, которые в нем нуждаются.

test:
    stage: test
    before_script:
        - *enable_ssh
    script:
        - ...

Добавление этого в .gitlab-ci.yml помогло мне. (как упомянуто здесь: https://docs.gitlab.com/ee/user/project/new_ci_build_permissions_model.html#dependent-repositories)

before_script:
    echo -e "machine gitlab.com\nlogin gitlab-ci-token\npassword ${CI_JOB_TOKEN}" > ~/.netrc

(Я попытался настроить SSH_PRIVATE_KEY, как указано в одном из ответов выше, это не сработает)

Если вы используете изображение альпийских гор (возможно, docker:latest или docker:dind), ваш before_script может выглядеть следующим образом:

before_script:
    - apk add --no-cache openssh-client git
    - mkdir -p /.ssh && touch /.ssh/known_hosts
    - ssh-keyscan gitlab.com >> /.ssh/known_hosts
    - echo $SSH_KEY | base64 -d >> /.ssh/id_rsa && chmod 600 /.ssh/id_rsa
    - git clone [email protected]:mygroup/myproject.git

1. Если ваш исполнитель CI работает в модели контейнера, вам необходимо использовать ключ развертывания. документ: https://docs.gitlab.com/ee/user/project/deploy_tokens/#git-clone-a-repository

git clone https://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git

2. Создайте свой токен развертывания
3. Добавьте свой токен в переменную конвейера CI
4. убедитесь, что в вашем контейнере есть git, и измените URL-адрес git на вместо

  image: docker:latest
  before_script:
    - apk add --no-cache curl jq python3 py3-pip git
    - git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.come/".insteadOf '[email protected]:'

для замены URL: https://docs.gitlab.com/ee/user/project/working_with_projects.html#authenticate-git-fetches

Кажется, наконец-то появился разумный решение.

Короче говоря, с GitLab 8.12 все, что вам нужно сделать, это использовать относительные пути в .submodules, и git submodule update --init будет просто работать