git 如何为 Gitlab 运行程序启用通过 SSH 的克隆？

How do I enable cloning over SSH for a Gitlab runner?

提问by Steven van der Merwe

I am having some trouble cloning large repositories over HTTP on my Windows Gitlab runner. I've tried several methods to do shallow clones or disable clone compression. Still no luck.

我在 Windows Gitlab runner 上通过 HTTP 克隆大型存储库时遇到了一些问题。我尝试了几种方法来进行浅层克隆或禁用克隆压缩。仍然没有运气。

Cloning the same repository over SSH works great as a temporary solution and I would like to get this working on our Gitlab CI process.

通过 SSH 克隆同一个存储库作为临时解决方案非常有效，我希望在我们的 Gitlab CI 过程中使用它。

The issue now stands where I have no idea how to use SSH as a clone method for the gitlab-multi-runner. It just seems to use HTTP as a default, and my only options regarding cloning is whether it will do a full clone or a fetch.

现在的问题是我不知道如何使用 SSH 作为 gitlab-multi-runner 的克隆方法。它似乎只是默认使用 HTTP，而我关于克隆的唯一选择是它是执行完整克隆还是获取。

Can someone explain how I could get that clone/fetch to work on a runner over SSH instead of HTTP?

有人可以解释我如何让克隆/获取通过 SSH 而不是 HTTP 在运行器上工作吗？

Gitlab Version: GitLab Community Edition 8.10.7

Gitlab 版本：GitLab 社区版 8.10.7

Thanks!

谢谢！

回答by Maciej Treder

According to:

根据：

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

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

You need to:

你需要：

1. Create a new SSH key pair with ssh-keygen
2. Add the private key as a Secret Variable to the project
3. Run the ssh-agent during job to load the private key.

1. 使用 ssh-keygen 创建一个新的 SSH 密钥对
2. 将私钥作为秘密变量添加到项目中
3. 在作业期间运行 ssh-agent 以加载私钥。

Example gitlab_ci.yml:

示例 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'

回答by ecoe

As a newcomer to gitlab, I've managed to hack a workaround to this issue as I also haven't found a built-in way to change the default cloning process (although here is a recent comment about how it can be done).

作为 gitlab 的新手，我设法解决了这个问题，因为我还没有找到更改默认克隆过程的内置方法（尽管这里是最近关于如何完成的评论）。

By disabling the automatic cloning process, you can effectively override its behavior completely by simply writing your own cloning process in a before_script. Only for the purposes of example does the below show how to accomplish this for HTTP cloning but could be adapted for sshcloning (if you're trying to use HTTP cloning you should use the built-in cloning process and the config.toml):

通过禁用自动克隆过程，您可以通过简单地将自己的克隆过程编写在before_script. 仅出于示例的目的，下面显示了如何为 HTTP 克隆完成此操作，但可以适用于ssh克隆（如果您尝试使用 HTTP 克隆，则应使用内置克隆过程和 config.toml）：

1. Create a new user called "gitlab-runner" and generate their user auth token for later use (or in your case, you would generate ssh keys).

2. Disable cloning process for runner by adding the following variable in either your project or group settings: .../settings/ci_cd

   key: GIT_STRATEGY

   value: none

3. Clone your repo in a before_scriptsuch as:

1. 创建一个名为“gitlab-runner”的新用户并生成他们的用户身份验证令牌以供以后使用（或者在您的情况下，您将生成 ssh 密钥）。

2. 通过在项目或组设置中添加以下变量来禁用跑步者的克隆过程： .../settings/ci_cd

   密钥：GIT_STRATEGY

   值：无

3. 将您的 repo 克隆为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

Note: Here are the relevant variables I also configured in step 2 rather than hard coding them in the script:

注意：以下是我也在第 2 步中配置的相关变量，而不是在脚本中对其进行硬编码：

• RUNNER_TOKEN: "Runner Token" value listed in the Admin "Runners" menu for the particular runner you are trying to run.
• GITLABRUNNER_USER_AUTH_TOKEN: This is the auth token you generated in step 1.

• RUNNER_TOKEN：在您尝试运行的特定跑步者的管理“跑步者”菜单中列出的“跑步者令牌”值。
• GITLABRUNNER_USER_AUTH_TOKEN：这是您在步骤 1 中生成的身份验证令牌。

回答by perden

I had a similar problem that necessitated the use of cloning via ssh: using the virtualboxexecutor with very old guest linux OSes. I was able to get around it by doing a few small configuration changes:

我有一个类似的问题，需要通过 ssh 使用克隆：在virtualbox非常旧的来宾 linux 操作系统上使用执行程序。我能够通过进行一些小的配置更改来解决它：

1. Create a deploy keyfor access to the project.

2. Force the user account that will perform the clone to use the deploy key. In my virtualboxcase, I modified the ssh configuration for the user that's configured for virtualboxin /etc/gitlab-runnner/config.toml.

1. 创建用于访问项目的部署密钥。

2. 强制执行克隆的用户帐户使用部署密钥。就我virtualbox而言，我修改了为virtualboxin配置的用户的 ssh 配置/etc/gitlab-runnner/config.toml。

~/.ssh/config

~/.ssh/config

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

1. Configure the runner to perform the clone via ssh in /etc/config.toml.

3. 将运行器配置为通过 ssh 执行克隆/etc/config.toml。

/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
  '''

  # [...]

Here's a breakdown of the additions to config.toml:

以下是对添加内容的细分config.toml：

• The GIT_STRATEGY=noneenvironment variable disables the runner's internal git cloning mechanism. (See the Git Strategysection of the CI/CD reference)
• The pre_build_scriptperforms the actual clone using predefined CI/CD environment variables. In my case, this is a bash script to perform something similar to what a GIT_STRATEGY=fetchmight do.
• If pre_build_scriptis multi-line, the output of the runner will only show the first line. Having a comment as the first line helps add clarity to the runner output.
• pre_clone_scriptis not used here. It's disabled since the environment has GIT_STRATEGY=noneset.

• 在GIT_STRATEGY=none环境变量禁用亚军的内部混帐克隆机制。（请参阅CI/CD 参考的Git 策略部分）
• 在pre_build_script执行实际的克隆使用预定义的CI / CD环境变量。就我而言，这是一个 bash 脚本，用于执行类似于 aGIT_STRATEGY=fetch可能执行的操作。
• 如果pre_build_script是多行，运行程序的输出将只显示第一行。将注释作为第一行有助于增加运行器输出的清晰度。
• pre_clone_script这里不使用。由于环境已经GIT_STRATEGY=none设置，它已被禁用。