Как включить клонирование через SSH для бегуна Gitlab?

Как новичок в gitlab, мне удалось найти обходной путь к этой проблеме, так как я также не нашел встроенного способа изменить процесс клонирования по умолчанию (хотя вот недавний комментарий о том, как это можно сделать).

отключив процесс автоматического клонирования, вы можете эффективно переопределить его поведение полностью, просто написав свой собственный процесс клонирования в before_script. Только в целях примера ниже показано, как это сделать для клонирования HTTP, но его можно адаптировать для ssh клонирования (если вы пытаетесь использовать клонирование HTTP, вам следует использовать встроенный процесс клонирования и config.toml):

1. Создайте нового пользователя с именем gitlab-runner и сгенерируйте его токен аутентификации пользователя для последующего использования (или, в вашем случае, вы должны сгенерировать ключи ssh).

2. Отключите процесс клонирования для бегуна, добавив следующую переменную в настройки вашего проекта или группы: .../settings/ci_cd

   ключ: GIT_STRATEGY

   значение: нет

3. Клонируйте свое репо в before_script, например:

before_script:
  ## clean the working directory
  - BUILD_DIR=/home/gitlab-runner/builds/$RUNNER_TOKEN/0
  - CLONE_DIR="$BUILD_DIR/$CI_PROJECT_PATH"
  - cd $BUILD_DIR
  - rm -rf $CLONE_DIR
  - mkdir -p $CLONE_DIR

  ## clone the project each time (inefficient, consider performing fetch instead if it already exists)
  - git clone http://gitlab-runner:$GITLABRUNNER_USER_AUTH_TOKEN@server:8888/${CI_PROJECT_PATH}.git $CLONE_DIR
  - cd $CLONE_DIR

Примечание. Вот соответствующие переменные, которые я также настроил на шаге 2, а не жестко закодировал их в скрипте:

• RUNNER_TOKEN: Значение токена бегуна, указанное в меню «Администраторы бегунов» для конкретного бегуна, которого вы пытаетесь запустить.
• GITLABRUNNER_USER_AUTH_TOKEN: это токен аутентификации, который вы создали на шаге 1.

Дополнительная информация:

Вы можете избежать описанного выше подхода поддельной учетной записи, выполнив вместо него Развернуть ключи. Или, если вопросы безопасности доступа к любому проекту вызывают озабоченность, Разверните токены являются альтернативой с большим контролем безопасности. Для сравнения см. документы:

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

Ключ развертывания - это SSH-ключ, который вам нужно сгенерировать на своем компьютере. Токен развертывания создается вашим экземпляром GitLab и предоставляется пользователям только один раз (во время создания).

Ключ развертывания действителен, пока он зарегистрирован и включен. Развертывание токенов может зависеть от времени, так как вы можете контролировать их срок действия, задав для них дату истечения срока действия.

Вы не можете войти в реестр с помощью ключей развертывания или выполнять с ним операции чтения / записи, но это возможно с помощью токенов развертывания. Чтобы использовать ключи развертывания, вам нужна пара ключей SSH, но не токены развертывания.

В соответствии с:

https://docs.gitlab.com/ee/ci/ssh_keys/README.html

Тебе надо:

1. Создайте новую пару ключей SSH с помощью ssh-keygen
2. Добавьте закрытый ключ в качестве секретной переменной в проект
3. Запустите ssh-agent во время задания, чтобы загрузить закрытый ключ.

Пример gitlab_ci.yml:

before_script:
  # Install ssh-agent if not already installed, it is required by Docker.
  # (change apt-get to yum if you use a CentOS-based image)
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'

  # Run ssh-agent (inside the build environment)
  - eval $(ssh-agent -s)

  # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
  - ssh-add <(echo "$SSH_PRIVATE_KEY")

  # For Docker builds disable host key checking. Be aware that by adding that
  # you are suspectible to man-in-the-middle attacks.
  # WARNING: Use this only with the Docker executor, if you use it with shell
  # you will overwrite your user's SSH config.
  - mkdir -p ~/.ssh
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  # In order to properly check the server's host key, assuming you created the
  # SSH_SERVER_HOSTKEYS variable previously, uncomment the following two lines
  # instead.
  # - mkdir -p ~/.ssh
  # - '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" > ~/.ssh/known_hosts'

У меня была аналогичная проблема, которая требовала использования клонирования через ssh: использование исполнителя virtualbox с очень старыми гостевыми ОС Linux. Мне удалось обойти это, внеся несколько небольших изменений в конфигурацию:

1. Создайте ключ развертывания для доступа к проекту.

2. Заставить учетную запись пользователя, которая будет выполнять клонирование, использовать ключ развертывания. В моем virtualbox случае я изменил конфигурацию ssh для пользователя, настроенного для virtualbox в /etc/gitlab-runnner/config.toml.

~ / .ssh / config

Host gitlab.example.com
  Preferredauthentications publickey
  IdentityFile ~/.ssh/deploy-key

3. Настройте бегун для выполнения клонирования через ssh в /etc/config.toml.

/etc/config.toml

[[runners]]

  # [...]

  environment = ["GIT_STRATEGY=none"]
  pre_build_script = '''
    # Fetching using ssh (via pre_build_script in config.toml)
    if [ -d "${CI_PROJECT_DIR}" ]; then rm -rf "${CI_PROJECT_DIR}"; fi
    mkdir -p "${CI_PROJECT_DIR}"
    cd "${CI_PROJECT_DIR}"
    git init
    git remote add origin "ssh://git@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git"
    git fetch origin "${CI_COMMIT_SHA}"
    git reset --hard FETCH_HEAD
  '''

  # [...]

Вот список дополнений к config.toml:

• Переменная среды GIT_STRATEGY=none отключает внутренний механизм клонирования git бегуна. (См. Раздел Стратегия Git справочника по CI / CD)
• pre_build_script выполняет фактическое клонирование с использованием предопределенных переменных среды CI / CD. В моем случае это сценарий bash, выполняющий нечто похожее на то, что может сделать GIT_STRATEGY=fetch.
• Если pre_build_script является многострочным, вывод бегуна покажет только первую строку. Комментарий в первой строке помогает внести ясность в вывод бегуна.
• pre_clone_script здесь не используется. Он отключен, поскольку для среды установлено GIT_STRATEGY=none.

Это сработало для меня, добавьте это в свой .gitlab-ci.yml

script:
  - git remote set-url --push origin git@$CI_SERVER_HOST:$CI_PROJECT_PATH.git

Это установит ваш URL-адрес push в файле .git / config, и бегун будет использовать его при отправке кода обратно в репозиторий git вместо URL-адреса, который использует ci-token.