Gitlab CI aka管道依赖中的上游触发

我似乎找不到这样一个工具所需要的最明显的CI特性：在另一个项目的管道完成后运行一个项目管道。您可以使用

trigger

执行此操作，但仅适用于下游触发，这与您希望的相反，如果您有一个项目是20个其他项目的核心依赖项，这些项目都需要重建

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

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

项目B，“取决于”项目A：

.gitlab ci.yml

from_upstream:
  stage: pre
  trigger:
    project: ProjectA

它所做的是在ProjectA管道[成功]完成时触发ProjectB构建

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

那么，有人能解释一下为什么GitlabCI缺少一个在Bambol和Hudson/Jenkins中已经存在了几十年的明显特性（即使在EE中也不可用）？如何使用Gitlab CI实现我所需的功能

更新： 对一些人来说，上下游的概念似乎真的令人困惑，因此，请澄清：上游项目A是并且必须始终与下游项目B分离，因为分离关注点是一件事，上游维护人员不可能也不应该知道他们的项目如何在下游使用

---

因此，所需的功能（同样，在Bambow和Jenkins中存在了几十年）是下游管道在上游管道上声明被动触发器，而不是在Gitlab CI中实现的主动触发器。

这里有多项目管道的文档和示例应用程序：

---

对于示例项目，名为“simple maven dep”的项目会触发依赖它的另一个应用程序（“simple maven app”）的管道。

我也遇到了同样的问题，在Jenkins上保留多项目管道的CI更容易。到目前为止，gitlab ci似乎只对简单的项目流有用。@makozaki是的，这似乎确实是一个案例再次阅读我的问题，它解释了这与我需要的正好相反。你所说的问题通过我提供的链接中的触发器得到了解决。如果您有一个库在X项目中使用，并且核心库发生了变化，那么X项目不需要重新构建以获得核心库中的变化吗？更不用说您使用curl和Gitlab CI REST API是绝对没有必要的，因为您可以直接使用它的名称触发另一个项目的管道。在您的情况下“simple maven app”（项目B）依赖于“simple maven dep”（项目A），后者有触发器。相反，可取且直观的是前者有触发器。同样的问题，我完全同意@YogSothoth…我有一个库和一个应用程序。但如果库发生变化，我不想告诉库项目构建应用程序（推送或顺流原则）。我希望在使用的库发生变化时构建应用程序（拉送或顺流原则）。这正是上文所述的示例多项目管线项目的另一种方式……遗憾的是，这似乎根本不可能……真的很糟糕。。。