按照惯例，昨天GitLab发布了有一个新版本13.9。该版本在DevSecOps做了大量的增强，安全警报仪表板可对高优先级警报进行分类，维护模式可保证对分布式团队的更好的维护，还有在可视性方面的增强，包括对DORA指标的额外支持， 以及提出了新的口号，让用户可以实现“更好、更快的产品！”。详细的功能请追随虫虫一起学习。

概述

确保生产环境的安全和可用性是当务之急，但是很难平衡。新安全告警仪表板可以区分需要立即阻止的可疑网络活动或仅需要进一步关注的可疑网络活动，从而帮助用户平衡安全性和可靠性，从而最大程度地减少对用户的干扰。在模糊测试覆盖率指数添加JavaScript和Python支持，从而更轻松地构建安全可靠的软件，并将结果传送到Security Dashboard中。

GitLab立足于服务分布式团队，新的维护模式可在执行更多管理任务时实现实例的只读可用性，从而进一步减少停机时间。可变的Gitaly复制因子改善了数据存储的可扩展性和冗余性，用户可以将群集调整到自己的存储和预算约束，同时还可以进行水平扩展。

可见性是扩展DevOps的另一个核心要求，并且组级别的Release Analytics（分析）继续增加了对DORA指标的支持，而DORA指标现已汇总到组中的项目中。该单元测试报告新的失败测试计数器和一个新的合并请求数指标，平均时间合并。

对于DevOps的新手，或者是更新了停滞不前的工作，那么发出“更快提供更好的产品”的命令听起来就像是“事半功倍”。这可能会违反直觉。但是，DevOps是答案，而自动化是实现两者的关键。

确保构建和测试更快的一种可靠方法是寻找配置中的冗余。13.9中的新功能通过启用重用CI/CD配置的管道来从任何作业中节省时间。

大规模自动化通常需要减轻复杂性。将管道配置分解为许多文件后，可以查看该配置的扩展版本。新版本中使用父子或多项目管道的部署过程还可以使用资源组来管理跨阶段，作业甚至项目的并发。

GitLab 13.9中主要功能改进

维护模式（PREMIUM及以上）

系统管理员有时会在GitLab实例上执行维护操作，以使其保持最佳性能。管理员希望在进行这些操作时为其用户提供最高级别的访问权限。例如，实现辅助站点执行故障转移测试，作为公司业务连续性计划的一部分。在故障转移之前，需要暂停更改一小段时间，以确保辅助节点完全同步。在GitLab 13.8之前，只能通过限制用户登录来说实现，但是这会阻塞整个UI，并使用户无法访问GitLab。

GitLab 13.9新增加维护模式，可以在应用程序级别禁用写操作。该模式下，GitLab对于所有非管理员用户实际上都处于只读状态（管理员仍然能够编辑应用程序设置，并且后台作业可以继续）。普通用户可以登录到GitLab，查看界面并执行其他只读操作，例如git clone或git pull。使用维护模式，系统管理员可以执行维护操作，例如故障转移到辅助站点，而对常规用户的干扰最小。

目前，GitLab已经支持零停机时间更新，并且不需要启用维护模式即可使实例保持最新。

组级别发布Analytics（ULTIMATE）

在GitLab 13.9中，可以查看组级别的发布分析。为用户提供了与该组关联的每个项目的所有发行指标的汇总视图。可以查看属于该组的发行版以及与发行版关联的项目百分比。此功能还可以作为在组级别支持DORA 4指标的第一个迭代。

覆盖特定存储库的Gitaly Cluster复制因子（PREMIUM及以上）

之前Gitaly群集的复制因子是群集中的节点数。这使得无法为存储需求非常大的GitLab实例启用Gitaly Cluster。例如，具有50个节点的500 TB群集将需要配置25 PB的存储空间。为了使Gitaly Cluster可用于具有大量存储需求的实例，需要一种方法来指定一个复制因子，该因子应小于集群中节点的总数。

在GitLab 13.9中，可以将每个存储库的复制因子分别设置为小于集群中节点数量的任何数量。这仅允许复制最重要或活动的存储库，而将其他不太重要的存储库保留在较少数量的节点上。这将使组织能够根据自己的存储和预算限制调整群集。GitLab启用了一种为所有新创建的存储库配置默认复制因子的方法，这为用户提供横向扩展其Gitaly群集的必要手段。

在单元测试报告中轻松查看重复失败的测试

在检查管道中的失败测试时，很难判断失败测试是否是需要调查的合法失败，还是需要通过下一次执行的不稳定测试。

重复失败测试计数器的下一次迭代将重复失败测试计数器添加到单元测试报告中。新版本中，可以看到测试在默认分支上失败的频率，而无需与测试执行相关联的合并请求。

从任何作业中选择性引用CI/CD配置

在多个作业中重用相同的配置，有两个选择：添加YAML定位符（不能在不同的配置文件中使用）或使用extends重用整个配置。

在13.9中，添加了一个名为的新YAML函数!reference，该函数使用户将需要重用的部分配置以标签的形式在主配置文件引用使其成为CI/CD管道的一部分。

查看CI/CD配置的扩展版本

在配置管道时，可以像include和extends经常使用关键字。这些关键字有助于将一个较长的管道配置文件分解为多个文件，从而提高了可读性并减少了重复。不幸的是，这些关键字会使管道配置难以遵循。在某些配置中，管道配置文件主要由其他包含的配置文件的列表组成。

在新版本中，可以查看管道配置的版本，并将所有include和extends配置合并在一起。这样，更容易理解较复杂的管道流程并简化了调试过程。

多项目和父子管道的资源组

新版本中，可以使用资源组，如果部署过程中使用子管道或者多项目管道。管道可能会包含多个阶段，多个工作，甚至有可能跨项目。资源组可确保一次仅运行一个下游部署管道，因此可以安全地进行部署。之前，resource_group仅支持同一项目中的部署作业。

关注用户活动

GitLab用户现在可以关注其他用户在GitLab中的活动。关注用户可以帮助保持团队伙伴和关键项目贡献者的活动最新状态。可以在其他用户个人资料中关注或取消关注其他用户。要查看其活动，请转到顶级“活动”视图，然后选择“关注的用户”选项卡。

功能标记的Markdown链接

13.9中增加了功能标记Markdown链接。用户可以使用[feature_flag:<IID>]在讨论或评论中提及以引用特定功能标记。单击生成的链接以转到该功能标记的编辑页面。这样让功能标记上协作变得更加轻松和便捷。

要求审核者进行后续审核

合并请求作者收到审阅者的反馈。通常，需要重新审核此反馈，以确保所有问题均已得到适当解决。作为发布作者，需要与审稿人沟通对后续工作的需求。

对于已经审阅过合并请求的审阅者，新版本中可以请求重新审阅。此请求会触发一个待办事项和电子邮件通知，以提醒用户需要对自己的commit进行后续审核。

Jira Cloud应用程序的改进

现在，可以使用Atlassian Marketplace上的GitLab for Jira Cloud应用程序，将Jira Cloud项目数据与GitLab同步。该插件在“ Jira开发面板”中显示有关分支，提交，合并请求，部署和功能标志的信息。使用它可以查看正在进行的工作的当前状态，然后快速导航回到GitLab内部的那些页面。

为了使这些功能更易于使用，在过去的几个里程碑中，对初始设置过程进行了重大改进，现在连接GitLab名称空间比以往任何时候都容易。只需在Atlassian Marketplace上检查。

改善SAML超时体验（PREMIUM及以上）

当用户的GitLab组的SAML会话达到7天超时限制时，该用户将不再需要单击确认页面来续订他们的会话。manbetx客户端打不开会自动联系组的身份提供商以检查有效的会话并根据需要扩展它。此更改改善了组成员的体验，并为将来减少SAML会话超时打开了大门。

通过API管理项目访问令牌

在GitLab 13.9中，新引入了一个API来管理项目访问令牌。用于项目访问令牌的API Access对希望控制外部系统中或通过自定义自动化的项目访问令牌供应的用户启用集成。

出现用户忙碌状态和MR侧栏

在上一个版本中，添加了一个“用户忙碌”指示器，以指示协作伙伴是否可用于代码审查和其他任务。在13.9中中，在在发布和合并请求侧栏的“受让人”部分也显示了 “用户忙碌”指示器。

显示有关用户活动供稿的Epic评论（PREMIUM及以上）

截止目前，与Epic互动尚未在用户的活动页面上添加注释。这可能导致用户认为他们没有正确地创建，管理Epic或与Epic进行交互，或者可能只是使他们更难找到他们的近期活动。

从13.9开始，在用户活动页面和用户个人资料中可以查看所有Epic活动，并使用它来跟踪Epic协作。

VS Code中的GitLab CI变量自动补全

GitLab CI是快速且可高度配置的，但是要记住所有预定义的环境变量很难，并且错误的关键字字可能会导致.gitlab-ci.yml配置实效。为了简化配置GitLab CI管道的过程，GitLab工作流程的3.11.0版本在编辑.gitlab-ci.yml文件时为预定义的环境变量提供了自动补全功能。

自动补全对话框中的工具提示提供了有关变量用途的信息以及支持的GitLab和Runner版本。这些额外的信息确实有助于确保用户CI配置有效。

将变化标记为在合并请求中查看

在查看更改许多文件的合并请求时，要跟踪已查看的文件是一项挑战。当需要重新审阅或花费更多时间重新获取合并请求中每个文件的上下文时，审阅效率非常低。

13.9中，可以在合并请求中将文件标记为“已查看（Viewed）”，以帮助通知用户文件已被审核。此更改使审阅者可以快速跟上他们审阅的内容以及对于合并请求仍需要审阅的内容。

查看VS Code中的代码审阅注释

在GitLab Workflow for VS Code的先前版本中，可以查看VS Code中的合并请求更改。但是，查看合并请求提出的更改只是查看该更改并能够响应反馈的一部分。

在GitLab Workflow 3.10.0中，有关更改的注释现在可以作为diff视图的一部分使用。这大大提高了直接在编辑器中处理对合并请求提供的反馈的能力，而无需在VS Code和GitLab之间进行其他上下文切换。

组码覆盖率数据图（PREMIUM及以上）

以前发布的组代码覆盖率数据是查看组中项目当前测试覆盖率以及获取原始数据以在GitLab外部进行可视化的一种简便方法。现在，组代码覆盖率数据包括一个组的所有项目的平均覆盖率的图表，因此可以一目了然地看到该组的测试覆盖率随时间变化的趋势。

实例配置以控制最新的工件存储

在上一版本中，希望通过添加项目设置以禁用保留最新工件来改善存储消耗管理。自建实例的用户可能希望选择退出整个实例，因此新添加了一键式选项，以禁用为所有项目保留最新的工件。

CI/CD仪表板选项卡的专用URL（ULTIMATE）

在13.8中，在CI/CD Analytics下增加了对部署频率图表的支持。在新版本中，通过为每个选项卡引入URL来添加直接导航到每个CI/CD分析图表的功能，从而可以轻松地将此页面添加为书签或发送给其他同事以进行查看。

Kubernetes部署支持页面访问控制

在GitLab 13.8中，引入了对GitLab Pages的初始支持，可以通过Kubernetes部署GitLab，使用户可以轻松地部署静态网站。

在13.9中，新增加了Pages 的访问控制，可以选择将页面站点的访问权限限制为项目成员。GitLab Helm图表中支持pages所有功能。

子组的组Webhooks（PREMIUM及以上）

GitLab使您更容易使用子组Webhook构建子组管理自动化。创建或删除子组时将触发此Webhook。现在可以在不依赖连续API调用的情况下构建自动化，这很麻烦并且会给您的GitLab实例带来不必要的性能负载。

改善了项目成员列表的用户体验

新版版中对项目成员列表进行了重新设计，以帮助项目管理员快速识别其成员的关键属性，从而更有效地进行用户管理。它包括更具描述性的术语，新布局，所有列的标题，关键数据元素的工具提示等。

新的合并请求指标：平均合并时间（PREMIUM及以上）

项目级合并请求分析中提供了新的度量标准，即平均合并时间（MTTM）。MTTM是从创建合并请求（MR）到合并时间的平均时间。通过在日期范围选择器中选择不同的日期，可以查看合并MR的时间如何随时间变化，并了解在浏览和合并代码方面是否变得更有效率。

对组和项目问题进行批量编辑迭代（PREMIUM及以上）

新版本中，可以不必一次在一个问题上手动更新迭代，可以从组或项目的问题列表中批量更新迭代。

按里程碑过滤路线图（PREMIUM及以上）

战略计划或报告交流中，对当前进行中的工作需要能够重点关注和过滤路线图的视图。13.9中，通过按里程碑过滤可见的Epic，进一步完善里程图视图。

通过自定义提交消息应用建议

通过快速提出更改并单击按钮来应用给定的反馈，建议对合并请求进行更改可以使代码审核变得更快，更轻松。但是，有一个默认的提交消息，用于无法定制的应用建议，从而阻止用户描述更改并最终违反了项目的提交消息准则。

结果，合并请求作者常常被迫压缩整个合并请求的提交，或者不得不在本地手动应用建议，或者在应用建议后返回并重新编写提交。

在新版中，应用建议时可以编写自定义提交消息。这使作者和贡献伙伴可以接受建议，并遵循其项目的提交消息最​佳实践。如果未指定自定义提交消息，则使用默认的提交消息来提交建议。

使用GitLab API创建变更日志

之前，GitLab生成变更日志需要手动操作。版本管理者必须收集给定版本的所有更改，然后将它们手动添加到变更日志文件中，这既耗时又容易出错。为了简化该过程，13.9中添加了一个API，该API将基于提交历史为给定版本自动生成变更日志。通过为每个发行版提供一组一致且全面的变更日志，开发团队可以更好地与最终用户交流变更。

合并引用以进行合并请求中的更改

合并请求的diff已经通过计算git diff target...source其比较HEAD所述目标的与合并基础target和source。这很好，直到目标分支中的更改合并到源分支中为止，从而形成了完全的差异。

现在<default branch> (HEAD)，在查看合并请求的“更改”选项卡时，默认情况下将合并请求与之比较。这样可以在审核过程中提供更准确和最新的更改差异。

访问Webhook管道触发CI/CD作业中的有效负载

当使用Webhook触发管道时，无法从所得管道中的任何作业访问Webhook的有效负载。在某些情况下，有效负载会携带重要信息，这些信息可以确定触发的管道应如何工作。在新版本中，添加了一个新的预定义变量来捕获webhook有效负载，因此用户可以轻松地将其合并到触发的管道中。

借助产品内帮助更轻松地安装GitLab Runner

当使用共享运行程序时，要开始使用GitLab CI，需要安装GitLab运行程序并注册运行程序以在管道中执行作业。尽管GitLab Runner安装过程有充分的文档记录，其目标之一是使用户尽可能轻松地开始使用GitLab CI。该过程的第一步是发布一个新的GitLab Runner指导的安装模式窗口。使用此功能，可以选择目标平台，复制并运行安装命令，而无需离开GitLab UI。

重复的Maven上传设置

用户可以使用GitLab软件包注册表通过Maven或Gradle发布Java依赖项。默认情况下，可以多次发布相同的软件包名称和版本，类似默认的设置最常见的公共注册表的行为。

为了避免重复上传，新版本中为Package Registry添加了新的组设置，使用该设置可以选择是允许还是禁止重复的Maven或Gradle上传。如果不设置，默认情况下将允许重复。

可以使用GitLab API来修改该设置，也可以在“设置”>“软件包和注册表”配置。

键盘快捷键可在GitLab和GitLab Next之间切换

13.9中引入了一个键盘快捷键，可以在GitLab和GitLab Next之间切换。通过使用g和x键，该键可在GitLab的任何区域使用，可以轻松地实现GitLab和GitLab Next之间切换。

Kubernetes代理服务器的ConfigMap支持（PREMIUM及以上）

截止当前，使用Kubernetes代理服务器（kas）的用户都必须使用命令行参数来自定义其代理服务器安装。事实证明，这种设置非常不利于以进行大规模部署安装，而声明式，可重复设置是工作流的核心部分，并且许多参数都需要自定义设置。在13.9中，可以通过自定义配置安装Kubernetes Agent Server Helm Chart，这些自定义配置将与默认配置结合，从而可以轻松地将Agent Server部署与现有的观察性和监视工具集成在一起。

将事件分配给里程碑

并非所有事件的严重性都相同。为了恢复服务，时常需要同时并行处理很多事件。但是某些事件不太重要，可以将其排在其他工作之前，并可以排定特定的发布日期或实施。新版本中，可以从右侧工具栏中为里程碑分配低严重性事件，以便从问题面板管理它们。

Gitlab Runner 13.9

同期还发布了GitLab Runner 13.9。新增加的功能包括：

Kubernetes执行器增加对Nvidia docker运行时的支持；

控制缓存ZIP压缩级别；

显示工件/缓存上传进度；

在Windows帮助程序中将PowerShell核心升级到7.1.1；

在Linux上的Docker executor中启用PowerShell Core支持；

在Kubernetes执行器中启用PowerShell Core支持；

使用依赖代理自动进行身份验证；

使用配置的帮助程序映像更新Kubernetes执行程序中的权限；

在OpenShift上使用带有runner的自签名证书连接到gitlab实例。

Bug修复：

Gitlab CI脚本未正确传递上一个命令的退出代码的bug；

Windows服务“关闭超时”问题；

重复字符的可变屏蔽问题；

未使用配置映射中定义的config.toml的OpenShift Operator-concurrent属性。

GPU计算和智能调度支持

在类似机器学习等的计算密集型工作中，使用GPU可以极大提高性能。开发人员可以通过转发--gpu标志，将GitLab Runner配置为利用Docker执行程序中的GPU。还可以将其与Docker Machine的GitLab分支中的最新支持一起使用，可以让用户通过连接的GPU加速工作负载。

GitLab Helm chart改进

GitLab页面的访问控制支持Kubernetes部署。

可以以更可配置的方式在所有对象（例如部署和水平吊舱自动缩放器）上设置标签。每个子图表都有一个新common.labels设置。

可以启用代理协议支持，以在具有添加代理协议标头（例如AWS ELB）的上游代理的环境中支持SSH。

redis已更新至6.0.10和gitlab-exporter v10

Omnibus的改进

GitLab的存储库安装脚本现在将CentOS 7软件包用于Amazon Linux 2系统。Amazon Linux 2上现有的GitLab部署可以重新运行安装脚本以进行更新。注意目前尚未正式支持Amazon Linux 2 。

附带套件包软件分别升级为：redis 6.0.10、 logrotate 3.18.0，libtiff为 4.2.0

GitLab 13.9附带的Mattermost升级为5.31.1，其最新的扩展支持版本提供了错误修复，以提高稳定性并改进插件。此版本还包括安全更新，建议从早期版本进行升级。

安全和合规性审计

容器网络策略警报的安全告警仪表板（ULTIMATE）

新版本中新增加了全新的安全告警的仪表板。用户现在可以配置容器网络策略以将告警发送到安全告警仪表板。当必须对流量进行严密监控但不能在不对业务造成负面影响的情况下将其完全阻止时，该功能特别有用。可以在“安全性和合规性”>“威胁管理”>“策略”中配置警报， 然后在“安全性和合规性”>“威胁管理”>“告警”中查看告警。

JavaScript和Python支持覆盖率指导的模糊测试（ULTIMATE）

13.9中可以对Python和JavaScript应用程序运行覆盖率指导的模糊测试。和其他支持的语言工作流程相同，需要创建一个模糊测试作业以在管道中运行。当GitLab运行它时，模糊测试结果都会自动出现在“安全性仪表板”和管道的“安全性”选项卡中。

从漏洞创建Jira问题（ULTIMATE）

许多客户将Jira用作跟踪问题和工程工作。当将GitLab用于SCM和CI/CD时，可以利用Jira集成来传递来自MR的信息并提交到现有的Jira问题中。但是，还没有办法将有关安全扫描程序检测到的漏洞的信息自动反馈给Jira，需要用户手动将漏洞信息复制到新的Jira问题。

为了解决这个问题，13.9中引入了一种直接从漏洞的详细信息创建Jira问题的新功能。在现有的Jira集成设置中将其视为新选项。只需启用新选项，然后选择所需的Jira发行类型。可根据当前配置的Jira目标项目自动提取可用的问题类型。一旦启用，项目中可以从漏洞创建GitLab问题的所有位置将直接创建配置类型的Jira问题。

允许部署密钥推送到受保护的分支

在GitLab 12.0之前，具有写访问权的部署密钥可以将提交推送到受保护的分支。由于安全方面的考虑，已删除了对此的支持，但是许多用户还在使用它，他们需要这个方法来确保只有具有部署密钥的用户才能推送到其存储库。它还消除了使用服务用户或机器用户的需要，这为希望将部署密钥推送到针对该用例的受保护分支的任何团队捆绑了许可证。

新版本中已解决了此问题，现在部署密钥可以再次遵守受安全保护的最佳做法，同时推送到受保护的分支。通过转为部署密钥的隔离权限模型，用户现在可以选择“部署密钥”以直接从受保护分支的设置页面链接到受保护分支。

撤销PAT/SSH密钥时的电子邮件通知（ULTIMATE）

管理名称空间包括确保用户了解谁有权访问以及如何访问。为了提高个人访问令牌（PAT）的安全性，应该能够在适当的时候撤消用户的PAT。为了支持此控件，新添加了一个“撤消”按钮，自建实例的管理员根据需要撤消这些凭据。现在，可以在一个界面中从凭据清单管理用户的PAT和SSH密钥。

当管理员撤消或删除其PAT或SSH密钥时，使用用户现在还将收到电子邮件通知。这些改进为提供了集中控制权来管理用户的凭据，并为用户提供了透明性，因此他们可以采取措施以最小的中断替换其凭据。

通过机密性过滤路线图（ULTIMATE）

查看路线图时，曾经没有办法从主视图中隐藏机密Epic。如果想对外分享路线图，这可能会令人沮丧。

在新版本中，更新了搜索栏过滤器以包括机密性。现在，可以在另一层中优化路线图。

为sbt 1.3.0添加了依赖性扫描支持（ULTIMATE）

使用sbt1.3及更高版本的Scala项目的用户现在可以从“依赖项扫描”中受益。以前仅sbt支持1.2及以下版本。

改进的Android SAST支持

从GitLab 13.5开始，已经通过MobSF支持移动SAST。该分析仪更新为2.5版，其中包括对Android移动扫描功能的许多改进。主要改进包括：添加OWASP MSTG映射以改善漏洞信息，对Android 10 API 29的支持，xapk支持以及对Android的国家信息保障合作伙伴（NIAP）分析。

截止当前Mobile SAST安全扫描器是实验性的，需要通过CI变量SAST_EXPERIMENTAL_FEATURES启用。

.NET SAST扫描的多项目支持

GitLab安全扫描会自动检测代码语言并运行适当的分析器。使用monorepos，微服务和多项目存储库，单个GitLab存储库中可以存在多个项目。以前，.NET SAST工具只能检测存储库中的单个项目。在13.9中， NET SAST分析器现在可以智能地检测.NET项目中的多个解决方案文件（.sln），并报告其中的漏洞。对于具有多项目.NET存储库的用户来说，这使SAST扫描变得更易用、更精炼。

所有用户的“安全配置”页面

通过所有GitLab客户都可以使用SAST和Secret Detection，希望为启用可用安全扫描的开发人员改善体验。之前已经为Ultimate用户提供了指导性的配置体验，并且现在已经为所有用户提供了这种体验的简化版本。这种新的配置体验使开发人员更容易了解他们可以使用哪些安全扫描，查找相关文档并提供简单的启用工具。在该版本中，支持创建SAST合并请求的按钮。在将来的版本中，还将添加其他按钮以轻松启用其他扫描类型。

依赖关系扫描现在支持npm锁定文件v2（ULTIMATE）

现在支持具有使用npm 7的锁定文件版本2的节点项目的用户。以前，“依赖项扫描”将输出以下错误：[FATA] [Gemnasium] [2020-10-29T19:02:20Z] ▶ Wrong file format version。

在SAST扫描中扩展了对Ruby的支持

静态应用程序安全测试（SAST）通过允许开发人员在贡献代码和主动缓解代码时轻松识别常见的安全问题，从而帮助防止了安全漏洞。已经将RoRs SAST分析器（Brakeman）更新到新版本（v5），该版本增加了对大多数Ruby文件的支持，而不仅仅是Rails项目。此更改扩展了Ruby项目的类型，并引入了新的检测规则。如果一个自定义SAST.gitlab-ci.yml文件，或覆盖了GitLab SAST制动工，则可能需要更新CI文件以启用该附加扫描。

许可证扫描现在开始于其阶段（ULTIMATE）

以前，默认行为是在管道启动时启动许可证扫描。该行为是意外的，并且与其他GitLab Secure作业不一致。新版本中已更改了该默认行为，以便许可证扫描在启动阶段时开始，而不是在管道启动时开始。如果已自定义.gitlab-ci.yml文件，并且希望许可证扫描作业仅在其阶段开始时才开始，请删除该needs:[]语句。如果使用默认模板并希望还原行为，请添加该needs:[]语句。

对.NET 5的SAST支持

Microsoft .NET 5.0版本是.NET Core的下一个主要版本，与.NET Core或.NET Framework相比，它支持更多类型的应用程序和平台。已经更新了.NET SAST分析器安全代码扫描，以支持此新版本，现在SAST语言检测也支持该新版本，从而使GitLab SAST能够自动检测.NET 5项目。

漏洞报告活动过滤器（ULTIMATE）

漏洞报告通常是安全团队分类和管理漏洞的主要方式。当前的过滤和排序选项提供了快速的方法，将列表视图集中在漏洞的子集上，以实现更高效的工作流程。还可以查看具有相关问题或后续扫描表明已解决的所有漏洞。“活动”列一目了然地表明哪些漏洞可能已经准备好被关闭，哪些正在进行中，以及哪些漏洞可能需要引起注意。但是，此列不是可以过滤或排序的列！

现在，通过引入“活动”过滤器，可以进一步控制“漏洞报告”的经验。通过新的筛选器，可以在项目，组和安全中心漏洞报告中使用该漏洞，查看具有尚未解决，已解决但没有关联问题，有问题和已解决或没有活动的问题的漏洞。可用的筛选器选项是互斥的集，使可以精确钻取执行任何任务所需的漏洞列表视图。

支持PRIVATE-TOKEN使用Release-CLI创建发行版

在新版本中增加了使用release-cli和创建发布API文档中PRIVATE-TOKEN定义的的功能。通过允许连接项目级别或使用bot用户帐户的，可以覆盖创建发布的用户，并支持自动化。PRIVATE-TOKENPRIVATE-TOKEN

Vault JWT（JSON Web令牌）支持GitLab环境。

为了简化与HashiCorp Vault的集成，Gitlab提供了Vault JWT令牌支持。从启动开始，可以基于JWT中的数据限制访问。13.9中提供了一个新的维度来限制对凭据的访问：作业针对的环境。

此版本扩展了现有Vault JWT令牌，以支持基于环境的限制。由于environment名称可以由运行管道的用户提供，因此建议将新的基于环境的限制与已经存在的ref_type值一起使用，以实现最大的安全性。

使用依赖代理时自动进行身份验证

通过从Docker Hub代理和缓存容器映像，Dependency Proxy可以帮助提高管道的性能。即使打算将代理与CI/CD一起大量使用，但要使用此功能，也必须将凭据添加到DOCKER_AUTH_CONFIG CI/CD变量中或docker login在管道中手动运行。这些解决方案效果很好，但是当考虑.gitlab-ci.yml需要更新多少文件时，如果GitLab Runner可以自动进行身份验证会更好。

由于Runner已经能够通过集成的GitLab容器注册表自动进行身份验证，因此能够利用该功能来帮助您通过Dependency Proxy自动进行身份验证。

现在，使用Dependency Proxy从Docker Hub代理和缓存容器映像变得更加容易，并开始拥有更快，更可靠的构建。

性能改进

在GitLab 13.9中，在问题，项目，里程碑等方面做了性能上的优化。GitLab 13.9中的一些改进是：

多标签搜索速度提高5到10倍；

MR Analytics页面加载速度提高了7倍以上；

在Elasticsearch计数上设置1秒服务器端超时；

在搜索下拉菜单中加载标签时删除N + 1；

改进渲染路线图时的史诗限制；

blocked_by从问题链接查询中删除；

减少小型实例上的Puma内存消耗

默认情况下，GitLab使用的Web应用服务器Puma使用多个工作进程来提高性能。这对于扩展GitLab很重要，但也会导致内存消耗增加。

对于用户较少，资源有限的小型实例可能不需要多工作进程。对于这样的需求，新版中支持在单一模式下运行Puma，从而将静态应用程序的内存消耗减少了约250 MB。

Bug修复

GitLab 13.9中一些值得注意的错误修复是：

打开“管理员设置”页面会导致500错误；

当不存在filename属性时，单元测试报告未填充；

用点“.”构建。以他们的名字命名无法在用户界面中加载测试详细信息；

如果标签名称包含点“.”，则项目标签API返回“404 Label Not Found”。

SAST缺陷查找器在SAST CI作业中失败，出现UnicodeDecodeError错误;

SAST安全代码扫描崩溃：“index out of range error”;

内务管理未在Wiki仓库上运行，导致性能随时间下降;

根据漏洞详细信息创建问题-编辑的文本被丢弃;

GraphQL中的漏洞描述为空;

网络策略预览deny all显示为allow all;

将图像附加到票证时出现错误“Filenames contained invalid characters”;

not_adjacent 移动设计时出现错误;

路线图中的错误，其中史诗在用户界面中出现两次;

从子组添加子Epic时，添加了错误的Epic;

GEO：修复并发的VerificationBatchWorker作业;

gitlab-ctl Promotion-preflight-checks错误地失败，为0%;

UpdatePagesService作业可能导致备份作业失败，并显示错误“directory has vanished”;

依赖性扫描分析器未针对特定客户的每次扫描更新漏洞数据库。;

通过问题更新API创建的资源事件未遵循该updated_at参数;

API中的项目名称到路径转换会破点符号“.”;

迭代报告未正确定义范围;

“列出管道作业” GitLab API不再返回有关撤销作业的信息;

即使需要失败的作业，也不会跳过使用DAG的延迟和手动作业;

功能删除

集装箱扫描引擎Clair

变更日期：2021年5月22日

GitLab 14.0将用Trivy替换其容器扫描引擎。当前，GitLab使用开源Clair引擎进行容器扫描。GitLab 13.9弃用了Clair。这并不是一项艰巨的更改，因为希望继续使用Clair的客户可以通过将CS_MAJOR_VERSION变量设置为gitlab-ci.yaml文件中的版本3（或更早版本）来这样做。但是，由于不推荐使用Clair，因此请注意，从14.0版本开始，GitLab将不再更新或维护该扫描引擎。我们建议客户使用从GitLab 14.0开始的Trivy的新默认值进行定期更新和最新功能。客户可以提供反馈，并获得有关我们的公开折旧问题的更多详细信息。

容器注册表日志格式化程序

变更日期：2021年2月22日

GitLab支持的日志格式包括：

应用程序日志的文本，JSON和logstash日志格式。

用于访问日志的文本，JSON和组合日志格式。

13.9中放弃对logstash和组合格式支持，仅使用两个选项文本（用于开发）和JSON统一应用程序和访问日志的格式化程序。

删除Container Registry日志Hook

变更日期：2021年2月22日

容器注册表当前支持只能用于电子邮件通知的日志记录Hook。

基于日志条目的警报通常由单独的工具处理。据统计,用户都没有依赖此功能，GitLab也未使用它。该功能的实现与底层的日志记录库紧密耦合，这是在不影响可用功能的情况下切换依赖关系的能力的限制。

为了简化注册表功能和配置，将删除对日志记录Hook的支持。

删除Container Registry maxidle和maxactive Redis池设置

变更日期：2021年2月22日

当前为Redis连接池公开的一些配置设置与基础Redis客户端绑定，并且在替代库中没有等效设置。在我们开始改进Redis集成（例如增加对Sentinel的支持）的工作时，决定开始着手尝试以功能更丰富的替代方法来替换当前的Redis客户端依赖项，从而更好地为其提供支持。为此，需要替换绑定到当前客户端库的当前Redis池配置设置。预计将：

删除redis.pool.maxidle和redis.pool.maxactive设置。

添加redis.pool.size（最大连接数），redis.pool.minidle（最小空闲连接数）和redis.pool.maxlifetime（可以重用连接的最大时间）设置。

Container Registry删除对Bugsnag和NewReli格式

变更日期：2021年2月22日

Bugsnag和NewReli是容器注册表支持的错误报告服务。为了简化和合并支持的错误报告服务，增加对支持Sentry，并删除对Bugsnag和NewRelig的支持。

Container Registry不再支持TLS 1.0和1.1的

变更日期：2021年2月22日

出于安全性考虑，由于GitLab不再支持TLS 1.0和TLS 1.1。将对当前支持1.0（默认），1.1、1.2和1.3的GitLab容器注册表进行同样的操作。且默认为1.0。

我们将弃用对TLS 1.0和TLS 1.1的支持，并在使用它们时显示警告日志消息。这些版本的支持将被删除，并且TLS 1.2将成为默认版本。

删除secret_detection_default_branch作业

变更日期：2021年3月17日

为确保秘密检测同时扫描默认分支和功能分支，在托管模板中引入了两个单独的秘密检测CI作业。这两个CI作业secret_detection_default_branch和secret_detection在CI规则逻辑中造成混乱和复杂性。作为不推荐使用的一部分，将确定工作运行方式的rule逻辑（历史记录，分支上的提交，提交等）转移到了逻辑中。如果重写或维护的自定义版本，必须更新您的CI模板。强烈建议继承并覆盖托管CI模板，以便将来证明您的CI模板。将在2021年5月22日发布的GitLab 14.0中停止支持旧工作。

删除GitLab页面的磁盘源配置

变更日期：2021年5月22日

自GitLab 13.0起提供基于GitLab Pages API的配置，它将替换disk源配置，该配置将在GitLab 14.0中删除。建议不要使用disk源配置，而转而使用gitlab基于API的配置，因为disk将不再支持并且无法选择它。您可以通过gitlab_pages['domain_config_source'] = "gitlab"在gitlab.rb/etc/gitlab/gitlab.rb文件中进行设置来从“磁盘”源配置中迁移。建议在GitLab 14.0之前执行此操作，以便提前发现并解决所有潜在问题。

弃用使用Docker注册表API v1的请求

变更日期：2021年2月22日

上一个版本中，通过Docker注册表v1 API禁用了拉取功能.Docker在2019年6月删除了该功能，该功能使GitLab团队可以专注于为提供更多价值并针对当前注册表用例的功能和修补程序。

通过完成以下步骤，GitLab上的v1注册表API的现有用户可以移至v2注册表API：

将Docker Engine更新到17.12或更高版本，以便与v2注册表API兼容。如果在GitLab中具有v1格式的内容，则可以使用较新的Docker客户端（比1.12更新的版本）将其移至v2格式，以重建映像并将其推送到GitLab。

使用自定义规则集删除SAST分析器SAST_GOSEC_CONFIG变量

变更日期：2021年3月22日

GitLab 13.5中发布了SAST自定义规则集，为Go分析器（GoSec）的配置选项提供了更大的灵活性。为了提高灵活性，将放弃对SAST_GOSEC_CONFIG分析仪设置。该变量将在GitLab 13.10中弃用，并在GitLab 14.0中予以删除。如果覆盖或利用SAST_GOSEC_CONFIG了CI文件，则需要更新SAST CI配置或将其固定到GoSec分析器的旧版本。强烈建议继承并覆盖我们的托管CI模板，以便将来证明您的CI模板。将在SAST_GOSEC_CONFIG variable在2021年5月22日发布的GitLab 14.0中删除旧版本。

删除标签API中的版本说明

变更日期：2021年5月22日

GitLab 14.0将在标签API中删除对发行说明的支持。创建新标签时，将不再能够添加发行说明。也将不再能够通过标签API创建或更新发行版。请迁移以使用Releases API。

删除依赖性扫描

变更日期：2021年5月22日

以前，要排除DS分析器，需要将其从分析器的默认列表中删除，然后使用它DS_DEFAULT_ANALYZERS在项目的CI模板中设置变量。确定，在不失去新添加的分析仪优势的情况下，避免运行特定的分析仪应该更容易。因此，要求您从可用时迁移DS_DEFAULT_ANALYZERS到DS_EXCLUDED_ANALYZERS。以前，为了防止Gemnasium分析器在运行时获取咨询数据库，需要设置GEMNASIUM_DB_UPDATE env变量。但是，此文件未正确记录，并且其命名与等效BUNDLER_AUDIT_UPDATE_DISABLED变量不一致。因此，要求从可用时迁移GEMNASIUM_DB_UPDATE到GEMNASIUM_UPDATE_DISABLED。

发现漏洞，模糊测试作业将失败并显示allow_failure

变更日期：2021年5月22日

为了确保模块测试作业彼此一致，在14.0中，如果一个模糊测试作业发现漏洞，所有模糊测试作业都将开始失败。这些作业将allow_failure=true在其中设置，因此将收到警告，但如果发现漏洞，整个管道不会失败。

这是几种模糊扫描仪（例如Go和C ++模糊引擎）的当前行为。

无需采取任何措施即可使用此新行为。如果要作为脚本的一部分检查管道模糊测试任务的结果，请考虑这些脚本是否需要任何更新。

Git默认分支名称更改

变更日期：2021年4月22日

每个Git存储库都有一个初始分支。这是创建新存储库时自动创建的第一个分支。默认情况下，此初始分支名为master。从Git版本2.31.0开始（计划于2021年3月15日发布）会将Git中的默认分支名称从master更改为main。为了与Git项目和更广泛的社区进行协调，GitLab将更改SaaS（GitLab.com）和自GitLab 14.0开始的自建实例中新项目的默认分支名称。这不会影响已有项目。

删除GitLab OAuth隐式授权

变更日期：2021年5月22日

由于OAuth 2.1省略了隐式授权，GitLab将删除OAuth 2隐式授权流程。从14.0开始，将无法使用OAuth 2隐式授权流程创建新的应用程序。14.4中将不再支持现有的OAuth隐式授权流。请在版本14.4之前将现有应用程序迁移到其他受支持的OAuth2流。

GitLab Runner安装程序忽略skel目录

变更日期：2021年6月22日

在GitLab Runner 14.0中，skel默认情况下，安装过程将在创建用户主目录时忽略该目录。

Helm v2支持

变更日期：2021年5月22日

Helm v2于已于2020年11月停止支持，该stable存储库此后不久便从Helm Hub取消列表。GitLab 14.0的发布中（其中包括GitLab Helm图表的5.0版本），将不再支持Helm v2。

旧功能标志弃用

变更日期：2021年5月22日

传统功能标志在GitLab 13.4中变为只读。在GitLab 14.0中将删除对旧功能标记的支持。必须将旧版功能标志迁移到新版本。为此，可以先对旧式标志进行抓屏以进行跟踪。然后通过API或UI删除该标志（无需更改代码），并创建一个与您删除的旧标志同名的新功能标志。另外，请确保策略和环境与已删除标志匹配。

限制在GET/groups/:id/中返回的项目

变更日期：2021年5月22日

为了提高性能,将GET/groups/:id/API调用返回的项目数限制为100。要获取项目的完整列表，请使用GET/groups/:id/projects API调用。

将pwsh设为新注册的Windows Runner的默认外壳

变更日期：2021年6月22日

在GitLab Runner 13.2中，PowerShell Core支持已添加到Shell执行程序中。在14.0中，pwsh它将是新注册的Windows运行程序的默认外壳程序。Windows CMD仍可作为Windows运行程序的外壳程序选项使用。

从SAST_DEFAULT_ANALYZERS迁移到SAST_EXCLUDED_ANALYZERS

变更日期：2021年2月22日

在13.9之前，要避免运行一个特定的GitLab SAST分析仪，则需要将其从文件中较长的分析仪字符串中SAST.gitlab-ci.yml删除，然后使用它SAST_DEFAULT_ANALYZERS在项目的CI文件中进行设置。该字符串对执行的分析器列表进行了硬编码。通过反转此变量的逻辑以排除在外，而不是选择默认分析器，为了避免此问题。13.9开始，正在迁移到SAST_EXCLUDED_ANALYZERS我们的SAST.gitlab-ci.yml文件。建议在项目CI文件中使用自定义SAST配置的迁移到此新变量。如果尚未覆盖SAST_DEFAULT_ANALYZERS，则无需采取任何措施。SAST_DEFAULT_ANALYZERS 将在2021年4月22日发布的GitLab 14.0中删除。

将静态分析仪和工具固定到次要版本

变更日期：2021年3月22日

随着GitLab Secure扫描工具的成熟，需要在SAST分析仪的版本控制中增加更多的粒度。此项更改将使客户可以更轻松地专门设置要运行的分析仪的版本，从而为客户选择升级SAST扫描方式提供了更多控制。在13.10之前，GitLab为我们所有的SAST分析器和工具共享了一个主要版本号，并禁止使用语义版本号进行更新。

从13.10开始，GitLab SAST和Secret Detection将开始major.minor在.gitlab-ci.yml文件中使用版本固定，并将major.minor标签发送到分析器容器上。还将删除SAST_ANALYZER_IMAGE_TAG托管的SAST.gitlab-ci.yml CI模板中的major.minor变量，以使用每个分析器的标签为好。如果覆盖或维护的自定义版本SAST.gitlab-ci.yml，Secret-Detection.gitlab-ci.yml或依靠分析器x-y-stable标签，则需要更新CI模板。强烈建议继承并覆盖托管CI模板，以便将来证明您的CI模板。通过此更改，可以改用固定的major.minor版本进行覆盖，以更精细地控制将来的功能更新。将删除共享的主要版本固定和SAST_ANALYZER_IMAGE_TAGSAST.gitlab-ci.yml GitLab 14.0管理的变量，于2021年5月22日发布。

PostgreSQL 11支持

变更日期：2021年5月22日

PostgreSQL 12是GitLab 14.0中最低要求的版本。它为索引编制，分区和一般性能优势提供了重大改进。

从GitLab 13.7开始，所有新安装的默认版本均为12。从GitLab 13.8开始，单节点实例也将自动升级。如果还没有准备好升级，则可以选择退出自动升级。

在使用Patroni进行升级之前，多节点数据库实例将需要从repmgr切换到Patroni。然后可以更新GEO数据库并重新同步。

删除许可证合规性

变更日期：2021年5月22日

在13.0中，删除了许可证管理CI模板，并将其重命名为“许可证扫描”。通过警告用户切换旧模板，一直在提供向后兼容性。在14.0中，我们将完全删除许可证管理CI模板。

从包中删除/usr/lib/gitlab-runner符号链接

变更日期：2021年6月22日

在GitLab转轮13.3，一个符号链接从加入/user/lib/gitlab-runner/gitlab-runner到/usr/bin/gitlab-runner。在14.0中，将删除此符号链接，并将运行器安装在中/usr/bin/gitlab-runner。

删除FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL功能标记

变更日期：2021年6月22日

在GitLab Runner 13.1中，引入了Shell执行器sigterm，然后介绍sigkill了该过程。并添加了一个新的功能标志，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL因此可以使用以前的过程终止序列。在GitLab Runner 14.0中，将删除功能标记。

删除FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER功能标志

变更日期：2021年6月22日

在GitLab Runner 14.0中，将删除FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER功能标记。

删除Ubuntu 19.10（Eoan Ermine）软件包

变更日期：2021年6月22日

Ubuntu 19.10（Eoan Ermine）已于2020年7月17日星期五到期，在GitLab Runner 14.0中，我们将从软件包分发中删除Ubuntu 19.10（Eoan Ermine）。

删除Docker Machine自动缩放的非高峰时间模式配置

变更日期：2021年6月22日

在GitLab Runner 13.0中，GitLab Docker Machine执行程序引入了新的计时选项。在GitLab Runner 14.0中，计划删除非高峰时间模式下的旧配置选项。

删除成功和失败以完成构建度量标准转换

变更日期：2021年6月22日

在GitLab Runner 13.5中，介绍了failed并success声明了一项工作。为了支持普罗米修斯规则，选择了转换success/failure到finished度量标准。在14.0中，我们将删除转换。

删除对Windows Server 1903镜像支持

变更日期：2021年6月22日

在14.0中，将删除对Windows Server 1903的支持，该版本的支持已于2020-08-12停止。

在自定义执行程序中删除从step_script到build_script的翻译

变更日期：2021年6月22日

在GitLab runner13.2翻译step_script到build_script被添加到自定义执行。在14.0中，“ build_script”阶段将替换为“ step_script”。

更新Auto DevOps中稳定的Auto Deploy模板

变更日期：2021年5月22日

在GitLab 14.0中，将把Auto Deploy CI模板更新为最新版本。这包括对v2 auto-deploy-image的依赖关系的新功能，错误修复和性能改进。该最新模板已启用。除非您在项目中专门自定义Auto DevOps，否则它将使用稳定的模板，该模板依赖于v1 auto-deploy-image。

由于v1和v2版本不向后兼容，因此如果已经有已部署的应用程序，则项目可能会遇到意外故障。

对于GitLab自建实例，将安全使用Puma服务器

变更日期：2021年5月22日

官方不再建议使用Unicorn，将在GitLab 14.0中删除。必须先迁移到Puma，然后才能升级到GitLab 14.0。

删除合并请求术语WIP

变更日期：2021年5月22日

将合并请求的WIP（在进行中）术语重命名为“draft”，因为它更具包容性且不言自明。不再建议使用WIP术语，并在 GitLab版本14.0将删除。

删除14.0中的GEO外部数据包装器设置项目

变更日期：2021年5月22日

14.0中/etc/gitlab/gitlab.rb将不再支持下述的配置设置：

geo_secondary['db_fdw']
geo_postgresql['fdw_external_user']
geo_postgresql['fdw_external_password']
gitlab-_rails['geo_migrated_local_files_clean_up_worker_cron']

Gitlab 14.0中的旧存储删除

变更日期：2021年5月22日

从GitLab 13.0中开始，旧存储已被弃用，并将在GitLab 14.0中删除。

在升级到GitLab 14.0之前，必须 完全迁移到哈希存储。

升级更新

Omnibus版升级

通过Omnibus安装的自建实例可直接使用Linux包管理器可以升级。例如对CentOS:

yum updata/install gitlab-ce

就能自动完成升级：

docker安装的实例

先停止和删除旧的容器：

sudo docker stop gitlab
sudo docker rm gitlab

然后Pull官方最新镜像：

sudo docker pull gitlab/gitlab-ce:latest

重新启动容器（启动参数和以前保持一致）即可，比如:

sudo docker run --detach \
--hostname gitlab.example.com \
--publish 443:443 --publish 80:80 --publish 22:22 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest

Docker compose安装版本

通过：

docker-compose pull
docker-compose up -d

有关升级到GitLab 13.9的重要说明

Cohorts是GitLab自建实例的管理区域中可用的功能。显示了有多少个新用户已添加到GitLab，其中有多少成为活动用户，以及自添加以来，有多少用户继续每月使用GitLab。在GitLab 13.9中，同类群组已从“分析”部分移至“概述”>“用户”部分，以便可与其他用户指标一起发现。