今日 GitLab 官方博客宣布发布一个新的版本12.2。该版本带来了设计管理，并增加对管道的有向无环图来帮助团队优化管道，改善协作，管理括项目相互依关系。更多详细功能请追随虫虫一起学习。

更快，更灵活的管道

CI管道的目标是自动化手动构建和测试任务，加速软件交付，同时减少错误和bug。对于某些用例，GitLab CI/CD管道有时候并不是很有效。GitLab 12.2，中新增加有向无环图（DAG，Directed Acyclic Graphs）用来创建和管理详细作业依赖性，而不是依赖于顺序阶段。这样可使CI管道可以更快，更高效。

对于更复杂的管道，需要在上一阶段完成之前在一个阶段中启动作业。例如，当项目在多阶段管道中生成Android和iOS应用程序时，你可能希望iOS部署在所有iOS测试通过后立即启动，而无需等待所有Android测试也通过。为了解决这样的用例并提供强大而灵活的工具来定义复杂的管道，新版本为.gitlab-ci.yml添加了 needs ：关键字，用于定义作业之间的关系。

needs 关键字允许我们将一个作业指定为另一个作业的先决条件。成功完成先决条件作业后，下一阶段依赖它的作业会立即启动，而无需等待上一阶段中的其他作业完成。该功能在GitLab的内部是通过使用有向无环图（DAG）来实现的，当GitLab配置生成管道时，它使用复杂的规则集来确定作业的顺序，而不是简单地控制阶段所有作业。这样实现更高效的流水线执行，并为更高级的功能奠定基础。

设计管理（PREMIUM及以上）

软件开发是一项团队工作，目标是让每个人都能轻松做出贡献。在12.2中新增加了设计师角色和设计管理。

设计管理允许设计人员和开发人员通过留在设计中特定点的评论来更紧密地协作设计。该功能目前还只是源于GitLab内部设计师特定工作流程的开始，只有单一事实来源的问题的价值。通过提供一种结构化的方式来提供反馈并围绕设计进行讨论，希望广大前端设计人员参与该功能讨论和提供建议和做出贡献。设计管理目前还是 alpha功能 ，随时可能变化，另外设计管理需要启用大文件存储（LFS）。

跨项目合并请求依赖（PREMIUM及以上）

大的系统通常跨多个项目，在项目代码之间具有相互依赖性，尤其代码合并更顺序很重要。GitLab新版本支持跨项目合并请求依赖关系，可以定义这些依赖关系，防止由于代码错误的合并顺序而导致的问题。更少的错误可以减少返工，并更快地部署你的更改。

GitLab 版本12.2主要功能

按域限制组成员身份（PREMIUM及以上）

对于具有安全意识的组织，对项目的访问权限和组的控制非常重要，要确保只有合适的人员可以访问。新版中可以将组成员资格限制为仅使用与所选域名匹配的电子邮件地址的用户，如果你的域名为XXX，则只有使用XXX域名为后缀的电子邮件地址才能进入该组，这样防止项目所有者误添加非组织的用户，导致的权限泄露。

功能标志发布百分比（PREMIUM及以上）

现在可以选择”发布百分”作为功能标记的发布策略。”发布百分比”可以让每个环境和每个标志单独设置百分比。配置”百分比”卷展栏并启用该标志后，该功能将显示为已配置的百分比。这允许你执行受控的部署，监视目标环境的行为以确保结果符合预期。

功能标志的用户ID部署策略（PREMIUM及以上）

你现在可以选择”用户ID”作为功能标记的发布策略。用户ID策略允许你指定以逗号分隔的用户ID列表，然后仅为指定的用户切换功能标志。这可以让你针对特定群组或用户群的细分群体来定位测试功能。

合并请求中的安全批准（ULTIMATE及以上）

为了确保合并请求不会引入新漏洞的，新版本中需要特定人员审核并批准更改。这使使得团队更容易遵循你的合规性政策，并确保在未经明确批准的情况下，新漏洞不会无意中被引入代码库。

运行手动作业时指定变量

新版本中可以在启动手动作业时覆盖/提供正在运行的作业使用的新变量。这样可以更轻松地将可配置的自定义和/可重用作业设置为管道的一部分，并使实施管道作业时更容易进行故障排除。

Scoped环境变量功能迁移到Core免费版本

最初在GitLab Premium 9.4中引入，将环境变量范围扩展到特定环境的能力现在已经迁移到GitLab Core。在配置不同变量（比如，访问不同的环境相关基础结构的不同私钥）以及在开发生命周期中使用多个环境时，此功能提供了极大的灵活性。

NPM Registry支持个人访问令牌身份验证（PREMIUM及以上）

GitLab NPM Registry允许Javascript开发人员使用他们的GitLab实例构建，发布和版本化NPM包。NPM要求用户使用OAuth进行身份验证，在12.2之前，GitLab个人访问令牌不支持OAuth。用户被迫要生成他们自己的令牌（在GitLab之外），也无法使用双因素身份验证。

12.2新版本中开始支持使用GitLab个人访问令牌进行身份验证。GitLab个人访问令牌也可与双因素身份验证无缝工作，还可以设置范围和过期策略。只需使用个人访问令牌更新.nprmrc文件，然后开始将包发布并下载到GitLab NPM Registry。

维护者创建子组

对于优先考虑敏捷性的大型组织而言，子组是一种有价值的工具，可以在不断扩展的情况下保持实例的有序性。现在为组所有者提供选项，以授予维护者创建子组的能力。启用此选项后，组中的维护人员将能够独立且快速地移动，而无需团队所有者的干预以保持其项目的有序性。

改进差异扩展

查看代码变化差异时，大多数未更改的行都是隐藏的，因此很容易快速浏览到更改的行。但有的时候需要更多的背景，来获取更多的信息。GitLab 12.2中，隐藏线范围现在可以全部或逐步显示。之前隐藏的线条范围只能从范围的底部逐步显示。

设置代码所有者为组（PREMIUM及以上）

了解谁应该检查你的更改通常并不明显。将代码所有者分配给文件可以轻松实现。分配后，你可以在查看文件时查看代码所有者，并自动将其添加为合并请求批准者。

在GitLab 12.2中，可以分配组以及GitLab用户名和电子邮件作为代码所有者。分配为组可防止代码所有者在团队更改时失去同步，尤其是在使用LDAP管理组成员身份时。

设计管理上传

设计人员和开发人员现在可以通过GitLab的设计管理上传，在问题中协作设计资产。设计可以上传到问题内的新区域，以便于跟踪和协作。

容器 注册表 的多选删除

保持容器注册整洁很有必要。随着时间的推移，容器镜像会累积并占用大量磁盘空间。而且太多标签可能会显著的减慢容器注册表管理页面的加载时间，使其难以使用。

此前，维护容器注册表有一些选项，可以使用批量标记删除API和垃圾回收来自动清理，但需要你编写和维护额外的脚本。也可以从管理页面手动删除镜像和标签，但是需要一个一个手动操作，非常繁琐耗时。

新版本中改进了容器注册表的UI，可以支持更快地进行手动操作。可以一次选择多个标签，选择镜像时候也会自动选择所有相关标签。这样可以更轻松地维护注册表，降低存储成本并保持页面性能稳定。

环境级别的 Kubernetes 名称空间

在多个环境中使用相同的Kubernetes集群可以为你带来很高的效率。例如， dev和stage都使用相同的集群，则管理开销会下降，因为你只需要管理一个集群，并且基础架构成本会降低， Kubernetes可以将两个环境中的pod安排到较小的节点集上。

此前GitLab不能很好地支持该用例，项目中的所有环境都部署在同一个命名空间中。如果你希望每个环境具有单独的权限（例如，希望允许工程部署到dev但不是阶段），则需要为每个环境使用单独的群集。GitLab Kubernetes集成现在为每个项目环境使用专用命名空间，可以为每个项目环境单独精细配置权限，可以利用在多个环境中使用相同群集所带来的效率。

这允许Kubernetes用户在不同环境中重用相同的集群，而无需将所有环境部署到同一名称空间中。此外，云运营商现在能够为每个环境精细配置权限，以允许用户部署到某些但不是所有环境。

从K8s GitLab托管应用程序卸载相关组件

通过GitLab Kubernetes集成安装的组件，现在可以通过集群页面通删除。这些组件包括Helm，Cert Manager和Knative。

禁用组或项目电子邮件通知

无论用户单独设置如何，所有者现在都可以在组或项目级别禁用电子邮件通知。

如果在组级别激活它，它将级联到父组中的所有子组和项目。

锁定文件以防止单个主机上的多个运行器实例

在单个主机上运行多个实例 Git lab-runner可能会导致一些极其混乱且难以调试的行为。由于这不是预期用途，新版本引入了一个防止意外发生的文件锁定。

改进了@和:字符的变量掩码

新版本变量屏蔽中增加了对两个额外字符的支持， GitLab自动隐藏更加精细，提高对不同类型的信息的屏蔽能力。

通过API读写用户的管理员备注（STARTER及以上）

为用户编写管理员注释可以成为大规模管理GitLab用户库的有用工具。通过UI编写备注很快就会变得难以管理。用户API新版中增加对读取和写入管理员备注功能，使实例管理员比以往更容易管理用户备注。

安全仪表板作为组的默认视图（ULTIMATE及以上）

现在可以将组安全仪表板设置为组视图的默认界面。值得注意的是，这是基于单个用户设置的，所以团队中的每个人都可以选择他们最感兴趣的视图。

该设置可以让关注组的安全状态的安全团队和用户快速确定项目安全健康状况，而无需浏览菜单以查找信息。

列出项目star用户

star数是跟踪值得关注的项目的常用方法。由于社区贡献，新版本中可以通过单击项目页面上的星号数来查看已在UI中为特定项目加星的用户列表。列表也支持通过Projects API获取。

已加星标的项目也可在用户配置文件中查看。

合并请求的新推送选项

使用Git推送选项已经在GitLab合并请求中得到支持，并在管道成功时将其设置为合并，所有这些选项都来自原生的Git push命令（git 2.10以后支持）。这可以加速小更改的合并。

在GitLab 12.2中，GitLab已经支持新推送选项，包括：

设置合并时要删除的分支。

git push -o merge_request.remove_source_branch

更改合并请求的标题。

git push -o merge_request.title=”你的标题”

更改合并请求的说明。

git push -o merge_request.description=”合并说明”

批量编辑组级别的问题标签（PREMIUM及以上）

用户可以在特定项目中同时更改许多问题的标签。在GitLab 12.2中，新增在群组级别批量编辑许多问题标签的功能，从而可以更轻松地管理问题标签。

Git Blame API

Git blame是个非常有意思而且很有用的命令。用它可以清晰的显示没一行代码的来源、变化的完整历史。有关该命令用法可以参考虫虫的git之前的文章。

在GitLab 12.2中，新增加 Blame API可以直接通过GitLab获取该信息，而无需checkout源码。这有助于通过脚本和自动化，获取最近文件更改文件和变化的信息。

GET /projects/:id/repository/files/:file_path/blame

设计的版本控制（PREMIUM及以上）

在GitLab 12.2的设计管理中还引入了设计版本管理中。版本化设计提供了一种随时查看设计变更的简便方法，可以更轻松地跟踪变更和进度。

问题列表手动排序

从12.2开始，可以在手动模式下对问题列表进行排序，该模式允许在列表中拖放问题以为其分配相对顺序。

对于启用手动模式的所有”项目问题列表”和”组问题列表”，将在整个实例中保留和维护该排序。

从Bitbucket Server导入时按名称过滤项目

现有Bitbucket Server项目了一键导入GitLab。但是，如果有数千个项目，那么选择要导入哪些Bitbucket库可能具有挑战性。

在12.2中，采取措施通过在Bitbucket Server导入器页面上引入过滤器来简化迁移过程。可以在迁移页面指定要导入的项目名称来指定要导入的项目。

该项功能还会在后续会扩展到所有项目导入器中，值得期待。。

自动测试拆分完善示例

Gitlab已经支持parallel关键字，它可以提供并行测试（或者以并行方式运行作业）的控制和灵活性来设置，但需要大量设置，有时拆分逻辑会重复。有一些开源解决方案，比如Test Boosters通过将测试配置分成多个文件来处理这部分配置。

新版本还是更新了parallel关键字的文档，使其更加明显，并帮助更多团队充分利用他们的管道。

问题看板中嵌入Prometheus指标

度量标准图表有助于可视化更改的内容以触发事件。直接在问题中显示指标图表可让在生成新事件问题时立即开始，而无需打开仪表板以查找警报时间范围内的指标。在处理事件时，随叫随到的工程师可以使用嵌入式图表来分享他们通过浏览监控指标和日志而获得的信息和背景。事件结束后，执行回顾的团队将在一个地方包含所有图表，包括初始警报的指标和在故障处理期间完所有的所有操作。

要在问题中嵌入指标图表，只需在指标信息中心的图表上生成可共享的链接即可。我们可以使用dahsboard时间过滤器指定数据的时间范围，并会在URL中体现。在问题说明中粘贴此URL就能实现问题中嵌入该指标图。

当警报生成事件问题时，可以使用预先配置的模板。将度量图表添加到问题模板，自动嵌入显示作用于警报时间的指标图。

在指标仪表板下载CSV格式的Prometheus图表数据

许多人使用终端与GitLab进行交互。为了使终端显示内容，需要通过文本来传送图标信息。GitLab可以将图表数据以CSV文件下载，送入终端应用程序，可以通过访问所需图表右上角的下拉菜单并选择下载CSV的选项来下载图标的文本数据。

Omnibus改进

Mattermost的版本升级为 5.13。Mattermost是一个开源的Slack替代品，其最新版本包括新的社区插件，DevOps集成等。

GitLab 12.2中，已调整Unicorn工作程序的默认计数公式，以改进大型部署中并行请求的处理。公式从CPU+1更改为int(CPU * 1.5 +1)。

增加对Debian Buster提供GitLab 12.2二进制安装包。

nginx升级为1.16.1，TLS v1.3和ECDSA支持默认启用。

PostgreSQL 升级为9.6.14和10.9。

gitlab-monitor升级为4.2.0，graphicsmagick升级为 1.3.33，

为了提高安全性和可用性，默认情况禁用Redis KEYS指令。请控制该命令的使用或混淆这些指令。

添加对内容安全策略和nonce的支持，防止JavaScript XSS攻击。默认情况下禁用这些设置。

GitLab Runner 12.2

同期也发布了GitLab Runner 12.2。

GitLab Runner是一个Golang开发开源执行器，用于执行CI/CD作业并将结果发送回GitLab。

GitLab Runner 12.2带来的主要功能变化有：

锁定机制，以防止使用相同配置文件的gitlab-runner进程跑了多个实例。

注册命令的配置文件模板

GitLab Chart改进

gitlab Chart是在Kubernetes上运行GitLab的最佳方式。Chart中包含要开始的所有必需组件，并且可以扩展到大型部署。默认部署包括：

核心GitLab组件：Unicorn，Shell，Workhorse，Registry，Sidekiq和Gitaly

可选的依赖项：Postgres，Redis，Minio

使用Kubernetes执行程序的自动扩展，无特权的GitLab Runner

通过Let’s Encrypt自动配置SSL。

新版本中GitLab图表进行了以下改进：

Kubernetes支持最低版本为1.11

可以配置注册表的networkproxy设置。

可以配置gitlab-shell的Load Balancer设置。

可以为gitlab-migrations禁用Postgres准备语句的使用。

性能改进

GitLab 12.2在性能方面的改进有：

在问题板上更快地重新定位

标签API响应默认情况下不再包括问题和合并请求计数

更快地搜索项目或组的成员

异步加载非活动搜索选项卡上的结果计数

对合并请求窗口小部件数据使用基于ETag的缓存

减少在Markdown中呈现提交引用所需的Gitaly查找次数

减少呈现部署密钥列表所需的查询数量

减少渲染子模块所需的Gitaly查找次数

功能弃用

删除Kubernetes服务集成页面

Kubernetes服务集成页面已在12.2中删除，用GitLab 11.11中引入的实例级集群功能来替代该功能。

弃用日期：2019年8月22日。

GitLabcom新项目，组和代码段禁用了内部可见性

内部可见性设置对于有兴趣为任何注册用户提供项目的自我管理实例非常有用。在用户注册受限的情况下使用时，它可以成为鼓励内部使用的工具。

由于GitLab官网托管库用户注册是公开的，并且可供公众使用。任何人都可以注册并获得具有内部可见性的资源的读取权限，因此内部和公共设置之间几乎没有区别。有鉴于此，截至2019年7月30日，新项目，组和代码段只能创建为公共或私有。现有资源设置为内部可见的将迁移到附近的私人可见性。

迁移日期：2019年7月30日。

Ruby 最小版本为 2.6

GitLab 12.2开始，GitLab需要Ruby 2.6才能运行。Omnibus GitLab和GitLab Chart已经自带Ruby 2.6.3。运行Ruby 2.5或更早版本通过源安装的用户必须升级。

迁移日期：2019年8月22日。

升级更新

对于Omnibus安装的自建实例，可以使用包管理器可以升级。CentOS下可以直接通过yum updata/install gitlab-ce自动完成升级过程。

有关升级GitLab 12.2的重要说明

升级过程中会将备份现有Grafana数据，Grafana将重置为初始配置，GitLab SSO将是唯一可用的身份验证模式。

对已启用Rails的经过身份验证的Cookie加密，并且会自动升级旧会话。但是，不支持会话cookie的降级。因此，升级到12.2后，任何降级都会导致所有会话失效和用户退出。

与GitLab 12.0和GitLab 12.1类似，GitLab 12.2会自动将PostgreSQL版本升级到10.7。可以通过创建/etc/gitlab/disable-postgresql-upgrade跳过PostgreSQL的自动升级。