Gitlab 12.2 支持复杂 CI 依赖以及跨项目合并

Gitlab 近日发布了最新版本 12.2 ，旨在支持复杂的持续集成（CI）管道、团队协作和跨项目的依赖管理。此外，该版本为合并请求增加了新的推送选项，并使用了环境级别的 Kubernetes 命名空间，可以在多个项目环境中共享同一集群。

为了处理持续集成管道中复杂的工作依赖关系，GitLab 12.2 引入了对有向无环图（DAG）的支持:

大多数情况下，这将涵盖作业的进入或退出以及合并（菱形依赖项）等情况。当处理多平台构建或复杂的依赖关系网时会发生这种情况，例如操作系统构建或可独立部署但微服务相关的复杂部署图。

借助对 DAG 的支持，开发人员能够使用新的关键字 needs: 来定义工作的先决条件。根据 GitLab 官方解释，这是顺序阶段向前迈出的重要一步，而顺序阶段是以前唯一可用来指定工作相关性的机制。它还允许在管道阶段所需的作业完成后立即并发执行。

对复杂系统来说，Gitlab 另一个非常有用的新功能就是能够管理跨项目依赖的合并请求。当涉及到跨项目更改时，它可以让开发人员指定合并请求的顺序。这通常是非常棘手的，所以很多组织选择将多个项目合并到一个单一的存储库中，微软合并他们现有的.Net 资源库就是一个典型的例子。关于合并请求，GitLab 12.2 还支持一些新的推送选项，如更改请求标题和合并后删除分支等。

对于基于 Kubernetes 的开发者，GitLab 12.2 为提高资源使用效率，提供了一种可以在不同项目环境中共享相同 Kubernetes 集群的方法，比如开发和 stage 阶段，它们都具有私有的权限集。这可以通过为每个项目环境提供专用的 Kubernetes 名称空间来实现，因此我们可以将多个环境映射到同一个集群，并保证它们不会发生冲突。使用相同的集群基本上意味着使用更少的资源以及更少的使用管理。

Gitlab 12.2 还有一个新功能，就是为开发者和设计者提供额外的合作设施，但这仍处于试验阶段。设计管理确实可以将线框图和原型等设计资产与某一个问题关联起来，从而为设计师、开发人员和产品经理等不同的利益群体提供一个简单的方法，让他们只围绕一个单一问题来协作。

其它一些值得我们关注的新功能还包括：通过用户电子邮件的域名来限制组成员；能够推出针对特定用户的新功能，从而可以对谁应该测试该功能进行精细控制；对某些合并请求授权安全审计等。如果你需要一个完整的功能列表，请参阅正式的发布公告。

原文链接：

GitLab 12.2 Supports Complex Dependencies for CI Tasks and Cross-Project Merge Requests