Gitlab 如何在CI构建中访问多个存储库？

我们有一个由多个（非公共）存储库组成的项目

要构建整个项目，构建系统需要拥有所有存储库的文件（

master

分支）

有没有办法配置GitLab CI以提供所需的存储库

---

我想我可以在CI构建期间执行

git fetch

或类似操作，但是如何处理身份验证呢

您可以向所有项目添加部署密钥。然后在运行程序上配置部署密钥的私钥。在构建过程中使用普通git命令克隆运行程序上的存储库。这可能需要您的跑步者进行一些配置，但应该可以

您可以生成一个SSH密钥对并在所有运行程序上使用它，也可以为每个运行程序生成一个密钥对。要生成SSH密钥对，请遵循文档。私钥应该放在'gitlab runner'用户的

.ssh

目录中，以便

git

命令可以在克隆时显示它。公钥应作为部署密钥添加到GitLab项目中。在项目设置中添加一个部署键->“部署键”。

一些变通方法（我讨厌这个词！）可以解决我的ed问题：

使用

git子模块

，请参见

重新使用Gitlab定义的$CI_REPOSITORY_URL，甚至在子Docker容器中也可用。此env var已包含用户名和密码，可用于同一服务器上的另一个repo。请参阅.gitlab ci.yml中的代码片段：

-BASE\u URL=`echo$CI\u REPOSITORY\u URL|sed“s；\/*$CI\u PROJECT\u PATH.*；”` -REPO_URL=“$BASE_URL/thirdparty/gtest.git” -回购目录=第三方/gtest -rm-fr$回购董事 -git克隆$REPO\u URL$REPO\u目录

甚至在~/.git credentials文件中存储带有username\password的URL，并通过credential.helper配置git以使用它。所有进一步的“git clone”命令都将使用它

-echo存储git凭据，供“git clone”命令使用，无需用户名和密码。。。 -GIT\u凭证\u文件=~/.GIT凭证 -BASE\u URL=`echo$CI\u REPOSITORY\u URL|sed“s；\/*$CI\u PROJECT\u PATH.*；”` -echo$BASE\u URL>$GIT\u凭证\u文件 -git config--global credential.helper存储区--file=$git\u CREDENTIALS\u file 然而

在CI\CD领域工作了好几年之后，我认为需要将存储库链接为源的设计并不好

是的，在经典的CI工具（如Jenkins或TeamCity）中，您可以创建一个作业，在不同的子目录中获取多个Git回购

但我喜欢GitLab CI作为代码的管道方式，其中.GitLab-CI.yml控制这个repo的构建，您甚至不必考虑获取源代码的整个预构建步骤。 然后，这样的构建将发布二进制工件，下游项目\repo可以使用这些工件，而不是依赖项的源。它也更快

关注点分离

我不知道在我的.gitlab-ci.yml中是否有正式的方法来使用另一个项目的工件。但也有其他方法，如hook、Gitlab API，尽管这些定制解决方案需要维护

有一种更好的方法-将\获取工件发布到\外部广泛采用的包管理器。 根据您的语言，它可能是Maven、NuGet、npm、jFrog Artifactory、Nexus等。 此方法的另一个优点是，开发人员可以在其本地构建中遵循相同的过程，如果在.gitlab-ci.yml中定义了依赖项，这是不容易做到的

---

对于本机代码（Cxx）来说，这是一个更大的问题，主要是由于二进制接口的兼容性，但是像Conan.io等东西正在慢慢地迎头赶上。

如果您运行的是gitlab 8.12版或更高版本，则权限模型是无效的。与此新权限模型一起出现的还有CI环境变量

CI\u JOB\u TOKEN

。GitLab的高级版本将此环境变量用于触发器，但您可以使用它克隆repo

dummy\u阶段：
脚本：
-git克隆https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.instance/group/project.git

请您更准确地解释一下“然后在运行程序上配置部署密钥的私钥”的含义。编辑：我更新了答案，提供了更多详细信息。如果您还有问题，请告诉我。也许自2015年以来情况发生了变化，但在Gitlab.com上，跑步者似乎以

root

的身份运行东西。在我的例子中没有

gitlab runner

user。ssh/keys的最大问题是它允许运行程序的用户（gitlab文件的编写者能够访问和复制该ssh密钥）。请注意，上面的示例中正确记录了as，在GitLab url中，实例和组之间的分隔符必须是斜杠（…GitLab.instance/group/project.git），而不是冒号（…GitLab.instance:group/project.git），克隆才能成功。repo的SSH url采用后一种形式，这会导致错误地使用该格式。如果您需要从其他GL实例获取SSH密钥/令牌，则SSH密钥/令牌不会受到攻击。另一方面，您可以在这些repo的本地实例中创建导入的fork，并（使用另一个带有同步脚本的repo）不时对其进行同步。同意，部署密钥不是黑客攻击。我的答案是使用最少的权限来完成任务（并且不必更改任何配置）。deploykeys的优点是它提供了广泛的可能性（写访问、在gitlab实例之外的repos等）。@GrantHumphries，感谢这里的提示。我只是犯了那个错误，当时我正在拔头发，想弄清楚到底出了什么问题 - BASE_URL=`echo $CI_REPOSITORY_URL | sed "s;\/*$CI_PROJECT_PATH.*;;"` - REPO_URL="$BASE_URL/thirdparty/gtest.git" - REPO_DIR=thirdparty/gtest - rm -fr $REPO_DIR - git clone $REPO_URL $REPO_DIR - echo Storing git credentials to be used by "git clone" commands without username and password ... - GIT_CREDENTIALS_FILE=~/.git-credentials - BASE_URL=`echo $CI_REPOSITORY_URL | sed "s;\/*$CI_PROJECT_PATH.*;;"` - echo $BASE_URL > $GIT_CREDENTIALS_FILE - git config --global credential.helper store --file=$GIT_CREDENTIALS_FILE