Gitlab-CI 又名管道依赖项中的上游触发

Posted 2023-02-19

【中文标题】Gitlab-CI 又名管道依赖项中的上游触发

【英文标题】：Upstream triggering in Gitlab-CI aka pipeline dependencies

【发布时间】：2020-06-15 17:22:09

【问题描述】：

我似乎无法从这样的工具中找到最明显的 CI 功能：在另一个项目的管道完成后运行项目管道。您可以使用 trigger 执行此操作，但仅用于下游触发，这与您想要的相反，以防您有一个项目是 20 个其他项目的核心依赖项，这些项目都需要重建。

在这种情况下，您需要能够定义如下内容：

A 项目：没什么特别的，只是一条普通的管道

项目 B，“依赖”于项目 A：

.gitlab-ci.yml

from_upstream:
  stage: pre
  trigger:
    project: ProjectA

它的作用是在 ProjectA 管道 [成功] 完成时触发 ProjectB 构建。

相反，您必须在 ProjectA 中以类似的方式声明所有数十个下游，这既愚蠢又适得其反，尤其是当 ProjectA 是一个在任何地方都可以不断重用的核心库时。

那么，有人能解释一下为什么 GitlabCI 缺少 Bamboo 和 Hudson/Jenkins 几十年来一直存在的明显功能（即使在 EE 中也不可用）？以及如何使用 Gitlab-CI 做我需要的事情？

更新： 似乎上游/下游的概念对某些人来说确实令人困惑，所以澄清一下：upstream Project A 是并且必须始终与 downstream 项目 B 因为关注点分离是一回事，上游维护者不能也不应该知道他们的项目如何在下游使用。

因此，所需的功能（同样在 Bamboo 和 Jenkins 中已经存在了几十年）是下游管道在上游管道上声明被动触发器，而不是像当前在 Gitlab-CI 中实现的那样使用主动触发器。

【问题讨论】：

好吧，我在同样的问题上苦苦挣扎，在 Jenkins 上为多项目管道保留 CI 更容易。到目前为止，gitlab-ci 似乎只对简单的项目流程有用。

@makozaki 是的，确实是这样

如果你找到了一种优雅的方式来实现它，或者 GitLab 学会了处理这些东西，你能更新你的问题和/或提供答案吗？

【参考方案1】：

这里有多项目管道的文档和示例应用程序：https://about.gitlab.com/blog/2018/10/31/use-multiproject-pipelines-with-gitlab-cicd/ 和这里：https://gitlab.com/gitlab-examples/multi-project-pipelines

对于示例项目，名为“simple-maven-dep”的项目会触发依赖它的其他应用（“simple-maven-app”）的管道。

【讨论】：

再次阅读我的问题，它解释说这与我需要的相反。

您所说的问题已通过我提供的链接中的触发器解决。如果你有一个在X项目中使用的库，而核心库发生了变化，是不是需要重新构建X项目才能得到核心库的变化？

更不用说你完全没有必要使用 curl 和 Gitlab-CI REST API，因为你可以只使用它的名称来触发另一个项目的管道。

在您的情况下，“simple-maven-app”（项目 B）取决于“simple-maven-dep”（项目 A），后者具有触发器。相反，可取和直观的是前者有触发器。

同样的问题，我完全同意@YogSothoth ...我有一个库和一个应用程序。但是我不想告诉库项目如果库发生变化（推送或下游原则）来构建应用程序。我希望只要使用的库发生变化（拉动或上游原则），就可以构建应用程序。这与上面的示例多项目管道项目完全相反......可悲的是，这似乎根本不可能......真的很糟糕......

【参考方案2】：

只要管道完成另一个项目中的新标签，您就可以触发项目中的管道。此功能是在 12.8 版中引入的。它仅限于新标签，需要付费订阅。

https://gitlab.com/gitlab-org/gitlab/-/issues/9045