Continuous integration Gitlab CI多项目管道

目前，我正在尝试理解Gitlab CI多项目管道。 我想实现在另一条管道完成时运行一条管道

例如： 我有一个项目

nginx

保存在namespace

baseimages

中，其中包含一些配置，如fastcgi参数。ci文件如下所示：

stages:
  - release
  - notify

variables:
  DOCKER_HOST: "tcp://localhost:2375"
  DOCKER_REGISTRY: "registry.mydomain.de"
  SERVICE_NAME: "nginx"
  DOCKER_DRIVER: "overlay2"

release:
  stage: release
  image: docker:git
  services:
  - docker:dind
  script:
    - docker build -t $SERVICE_NAME:latest .
    - docker tag $SERVICE_NAME:latest $DOCKER_REGISTRY/$SERVICE_NAME:latest
    - docker push $DOCKER_REGISTRY/$SERVICE_NAME:latest
  only:
    - master

notify:
  stage: notify
  image: appropriate/curl:latest
  script:
    - curl -X POST -F token=$CI_JOB_TOKEN -F ref=master https://gitlab.mydomain.de/api/v4/projects/1/trigger/pipeline
  only:
    - master

现在，我希望有多个项目依赖于此映像，并在我的baseimage发生更改（例如新的nginx版本）时让它们重建

             baseimage
                 |
    ---------------------------
    |            |            |
project1     project2     project3

如果我向另一个项目添加触发器并在$GITLAB_CI_token处插入生成的标记，则外部管道将启动，但没有如文档中所示的组合图（）

如何显示完整的管道图？

---

我是否必须将依赖于我的baseimage的每个项目添加到baseimage的CI文件中，或者是否可以在每个项目中订阅baseimage管道？

多项目管道是中的付费功能，只能使用GitLab的Premium或Silver模型访问

查看此信息的方法是在文档标题的右侧：

---

在进一步挖掘文档之后，我发现了一句话，其中指出Gitlab CE提供了标记为核心特性的特性

我们有50多个Gitlab软件包，这是需要的。我们过去所做的是将提交推送到下游包，等待CI完成，然后将另一个提交推送到上游包，等待CI完成，等等。这非常耗时

您可以做的另一件事是手动触发构建，并可以手动确定顺序

如果这些都不适合你，或者你想要一个更好的方法，我构建了一个工具来帮助你做到这一点。我在内部使用了好几个月，意识到人们需要这样的东西，所以我做了一些工作来公开它

基本上，它会侦听Gitlab通知，当它看到对包的提交时，它会读取

.Gitlab pipes.yml

文件以确定项目依赖项。它将能够构建项目的依赖关系图，并在下游提交上构建消费者包

---

它告诉你它是如何工作的。然后，如果单击其中的版本历史记录，

…，则会显示

在GitLab 12.8的所有层中

从

13.10-pre

开始标记为premium，但在我的ee版本中，下行/上行链接的可视化功能正常

参考文献

在GitLab 11.8之前，有必要实现一个管道作业，该作业负责发出API请求以触发不同项目中的管道

在GitLab 11.8中，GitLab提供了一种新的CI/CD配置语法，以简化此任务，并避免需要GitLab Runner来触发跨项目管道。以下说明了如何配置桥接作业：

rspec：
阶段：测试
脚本：bundle exec rspec
登台：
变量：
环境：登台
阶段：部署
触发器：my/deployment

请检查，您使用的是GitLab Premium？我使用的是Kubernetes上最新的GitLab CE自托管。