其中某些设置已由组织隐藏或管理锁屏界面_GitLab 13.1：告警管理扩展，代码质量新工具和安全等...

昨天Gitlab官方博客发布了Gitlab新的月度版本Gitlab13.1，该版本搭理扩展了告警管理，新增加了改善代码质量的工具集以及安全和合规方面的内容，更多内容请和虫虫一起往下学习。

概述

自动化和扩展告警管理

告警对于应用程序维护是必不可少的，但是了解和分类引发告警的原因很费劲，需要耗费大量的时间，这会大大降低生产力和响应时间。Gitlab的告警管理汇总和排名所有服务的IT告警，以简化评估和补救，提高生产率，并帮助研究问题和解决。

13.1版本的告警方面带来很多功能扩展，包括告警分配，Slack集成以及告警分配时创建GitLab待办事项。

提高代码质量

部署速度只有在部署高质量代码时才重要。通过对最近修改的代码确定测试的优先级，开发人员可以立即解决Bug，而无需运行整个测试集。随时间推移的代码覆盖率跟踪会给开发人员和管理人员带来质量趋势，并且本机代码感知通过将相关信息集成到GitLab中来提高代码审查的速度和准确性。

增强并扩展安全性和合规性

安全对每个团队都很重要，Gitlab致力于降低建立全方位安全，合规的SDLC。在新的13.1版本中，Brakeman SAST扫描迁移到Core，对CE版本免费，可以允许每个Rails开发人员(每个产品层)在其源代码中扫描已知漏洞。对注重合规性的组织，新发布了针对网络容器策略的策略管理UI，并启用了将组级别漏洞导出到CSV文件的功能，以便进行审核或进一步的内部审核。

此外，安全仪表板也进行了有益的UX改进，添加了持久性过滤器和问题状态图标，以帮助用户在使用该工具时保持上下文。

GitLab 13.0主要功能改进

在GitLab中管理IT告警

进行故障处理时，响应者必须协调多种工具并评估不同的数据源，以收集和评估指标，日志和跟踪。与响应团队共享这些内容需要抓屏，然后将数据复制并粘贴到一个文档中，以使所有相关人都可以了解。这项工作需要手动的，费时耗力并且压力很大。它会导致告警疲劳，压力增加，士气低落，最重要的是还可能会导致告警被忽略。

GitLab引入了告警管理功能，可以在一个界面中汇总多个IT服务告警，从而帮助团队对告警进行分类并将其升级为突发事件。增加了在列表视图中对告警进行分类，查看告警详细信息，分配告警，更新告警状态以及从告警中创建突发事件的功能。

在即将到来的GitLab 13.2及更高版本中，Gitlab计划通过与PagerDuty集成，以显示相关指标和登录告警，关联运行手册以及创建Alert Integration Builder来改进告警和事件响应工作流程，以便运维员可以自助服务并实现GitLab与其他监控工具的集成。

将GitLab告警分配给团队成员

在GitLab 13.1中，可以将GitLab告警分配给团队中的特定用户，简化分类工作流程，委派需要调查的问题，并确保不会丢失任何严重告警。

告警列表的列排序

告警通常很嘈杂。为了使用户更容易快速找到最新或最严重的告警，现在可以按降序和升序对告警列表进行排序。

管道失败后自动通知

每当管道发生故障时，都会自动收到一封电子邮件通知。但是，如果管道在失败后成功，则不会发送自动通知，这需要手动检查管道的状态。在新版本中引入了一个功能自动通知管道在失败后是否成功。

告警分配记录在系统注释中

审核告警的对于反馈和改进很重要，但是在现实中中几乎没有时间记录以后需要的详细信息。在GitLab 13.1中，告警分配被添加到告警的系统注释中，可以在事后评估中对其进行讨论分析。

在Slack中协作进行GitLab告警

已经在Slack通知服务中添加了命令，可以将告警转发到Slack，以通知响应者中断，并使响应者无需离开中央通信平台即可开始协作。

分配告警时创建GitLab待办事项

响应者现在可以向团队成员分配告警，以帮助组织触发的告警，将问题委派给特定的团队成员进行调查。添加GitLab待办事项列表项会告诉团队成员需要注意的事项。

指标仪表板图例表格化

在没有适当上下文的情况下理解图表可能很困难。在GitLab 13.1中，通过以表格格式显示图表图例，可以使在检查图表时比较数据变得更加容易。

指标仪表板面板显示相关的URL

指标仪表板通常与其他仪表板相关。使用仪表板链接，可以显示指向相关的GitLab指标和Grafana仪表板的链接，这些链接保留了当前正在查看的仪表板的时间窗口。

指标仪表板面板显示外部链接

指标仪表板在方便向下钻取时最有用。在GitLab 13.1中，可以将自定义URL添加到指标仪表板中面板的"更多操作"菜单中，将指标面板和仪表板与其他指标仪表板以及团队使用的其他故障排除工具进行交流。

仪表板现在支持UTC

GitLab 13.1支持指标仪表板可以用UTC显示时间，从而使分散的团队成员能够一起工作以查看相同的时间序列数据，而不管团队成员的物理位置如何。

指标仪表板配置验证

配置仪表板YAML文件可能很复杂且容易出错。如果仪表板YAML定义无效，GitLab 13.1会自动对YAML文件进行验证，并通过显示警告消息来帮助诊断指标仪表板问题。

在环境中设置功能标记策略(PREMIUM及以上)

在新版本中，重新设计了功能标志UI，启用针对多种环境的设置策略。此前，随着环境数量的增加，管理功能标记和设置策略要困难得多。这项改进可以实现更灵活地在大规模环境中创建策略并将其应用于环境。

辅助功能测试合并请求小部件

在GitLab 13.1中，每个合并请求有一个小部件，小部件详细说明与已更改页面相关的可访问性。可以向开发人员显示待合并更改的影响，这有助于防止在合并和部署之前降低性能。

将设计线程标记为已解决

使用13.1，可以将任何评论标记为"已解决"，以表示该评论现已完成。更好的是，已解决的注释图钉将会从设计中消失，使得，设计人员可以专注于剩下的内容。如果需要重新访问某些内容，所有已解决的线程将在侧边栏底部的"已解决的注释"区域中。从那里，可以再次找到它们，并查看哪个修订版本适用于该修订版本。这将大大改设计的工作流程，让设计人员因专注于重要的事情。

合并请求评论移至核心

合并请求审阅最初是在GitLab 11.4中以GitLab Premium功能发布的，它使合并请求审阅者可以一次提交多个评论，从而减少了合并请求作者的通知，并允许一个更加统一和简化的审阅过程。在13.1的该功能已将迁移到Core对CE版本免费。

代码感知

代码审查是一个重要的过程，需要了解建议的更改和周围的代码，以了解是否已以可维护的方式进行。在编写新代码或查看对现有代码的更改时轻松浏览定义，使开发人员可以更好地理解所编写的软件。在查看新代码以及合并请求中的代码更改时，这非常有用。但是，设置可浏览的定义通常意味着配置外部工具和资源，或使用专用的IDE。有了GitLab，情况就不再如此。

在13.1版本中，以LSIF格式为基础，通过在项目.gitlab-ci.yml文件中添加新作业(指定LSIF报告)可以将GitLab的本机代码感知添加到任何项目中。生成后，无需外部工具和IDE，将鼠标悬停在代码中的对象上就可以显示的代码感知操作。未来的迭代将包括查找引用的能力以及API支持。

使用用户列表控制功能标志(PREMIUM及以上)

GitLab已经支持基于用户ID控制功能推出的功能。但是，为每个标志或环境重复添加更多用户是很麻烦的。为了使此过程更加方便，新添加了一个功能标记策略，称为"列表"。用户列表是使用API​​创建和修改的。创建后，通过为功能标记选择"列表"策略并选择适当的列表来使用它们。如果已经创建了列表，则可以立即使用它们。

图形代码覆盖率随项目的变化而变化

一个项目常常有一个代码覆盖率目标，但是开发团队可能对目标值随着时间的变化趋势不太了解。需要一种更简便的方法来跟踪代码覆盖率随时间的变化，而不会带来额外的麻烦。

现在，"代码覆盖率"图可以更好地了解代码覆盖率随时间变化的趋势。它显示管道中计算的覆盖率值的简单图形。

CI工作的需求满足(ULTIMATE)

新版本中允许用户在标准CI管道中配置作业，该作业在触发时会将所有现有需求标记为已满足。该CI作业可以是手动的也可以是自动的，并且像其他CI作业一样，可以配置为允许失败，因此不会阻止管道完成。未来的迭代将允许选择性地满足管道测试的要求，并允许客户执行手动验证以通过界面指示满足的要求。

在问题分析中探索趋势和详细信息(PREMIUM及以上)

问题分析使用户可以快速发现问题数据中的趋势。为了增强此功能，新版本中以表格形式列出了关键的详细信息，例如发行版本，状态，里程碑，权重，截止日期，受让人和作者。有了这种额外的可见性，用户现在可以跟踪图表之外的查询线索，并深入研究趋势背后的特定问题。

问题标题固定

在新版本中，无论阅读的是问题的哪一部分，问题标题将始终始终显示在问题的顶部。这确保始终具有上下文，无论单击的是深层对话线程的链接，在问题中滚动得很深还是正在使用多个类似问题的选项卡。

Web IDE中的EditorConfig支持

在项目上进行协作的开发人员遵循某些编码标准和样式，以保持项目中一致的可读性和格式水平。这种配置通常通过.editorconfig项目内部的文件来完成，该文件提供了缩进样式，缩进大小和行尾等说明。

打开文件时，Web IDE会.editorconfig在当前目录和所有父目录中查找命名的文件。如果找到配置文件，并且其配置与文件的路径匹配，则将在打开的文件上强制执行这些设置。Web IDE为EditorConfig的大多数广泛支持的功能提供支持，但除外charset。

在静态网站编辑器中隐藏YAML前缀

静态网站生成器在Markdown文件的开头占用两---行之间的前几行(前缀)，以格式化，配置或解析页面。标题不是要与页面内容一起显示，并且必须符合特定的格式规则。

GitLab的静态站点编辑器现在包含丰富的内容编辑体验，可以解析Markdown语法并以更熟悉的样式显示它。但是，在这种情况下，前端内容会被意外地呈现，并且使用可视编辑器对其进行编辑也可能会产生意想不到的后果。

GitLab 13.1中隐藏Markdown文件开头包含的任何YAML格式的前缀内容，以防止任何混乱或意外的格式更改。前缀事项在原始源代码编辑器中仍可编辑，可通过在静态站点编辑器右下角切换编辑器模式来使用。

在Web IDE中的Markdown中粘贴图像

在Web IDE中使用Markdown内容时，可能需要将图像添加到内容中。在大多数编辑器中添加图像都需要找到该图像，将其添加到目录结构中，然后通过markdown语法对其进行引用。

新版本中，Web IDE可以直接图像直接粘贴到编辑窗口中。将图像复制到剪贴板，将光标置于要显示图像的Web IDE中，然后粘贴。该图像会自动上传到项目中，并在内容中进行适当引用，从而大大加快了内容创建过程并降低了用户的复杂性。

通过管道状态和标签名称过滤管道

新版本中可以在管道页面上按管道状态或标记名进行过滤。通过过滤，查看所有管道以查找特定标签，或将管道列表缩小为特定管道状态(例如失败或跳过)更加容易。通过在现有过滤器选项中添加这些内容，可以比以往更加轻松地找到所需的管道，并节省您的时间。

实例级CI/CD变量

GitLab现在支持实例级变量。具有设置全局变量的功能，无需要为所有项目重复手动输入相同的凭据。该MVC引入了通过API对该功能的访问，并且该功能的下一次迭代将提供直接在UI中配置实例级变量的功能。

简化初始规则关键字配置的模板

可能很难弄清楚如何使用新的rules关键字，尤其是如果以前使用过only/except时，因为两者根本不同。rules关键字默认会创建一个合并请求管道，而only/except不会。

为了简化入门并rules更快地在管道中使用，新添加了两个最常见的workflow: rules配置作为捆绑模板。这些使立即工作变得更加容易，让用户专注于重要的事情。

更快，更轻松地作业工件下载

GitLab允许自定义管道作业工件，使它们更易于在GitLab UI中使用。此前，只能下载管道或作业的整个工件存档。

该功能将使直接访问任何报告工件文件的速度更快，更轻松。这对于可能要下载用于其他工具的安全扫描报告和代码质量报告特别有用。

使用GitLab 13.1，新增加了对下载以下类型的单个工件报告的支持：

· accessibility

· archive

· cobertura

· codequality

· container_scanning

· dast

· dependency_scanning

· dotenv

· junit

· license_management

· license_scanning

· lsif

· metrics

· performance

所有GitLab用户均可使用此功能。但是，工件报告类型在GitLab层之间有所不同。

蓝绿色部署文档

该文档一个使用NGINX进行蓝绿色部署的示例，示例直接从.gitlab-ci.yml文件中交换部署。如果使用类似的配置，此示例将帮助设置蓝绿色部署，并提供可针对其他类型的应用程序进行自定义的指导。

在搜索框下拉菜单中从项目中搜索组

在GitLab 13.1中，搜索下拉列表现在为您提供了从属于该组的项目中搜索组的选项。在GitLab 13.1之前，如果从项目进行搜索，则搜索下拉选项不包括在该组中。

更快地分配问题

GitLab喜欢使用户工作流程尽可能简单。现在，可以通过单击按钮将问题分配给评论者，在评论旁边。这样可以让注意力和精力集中在注释周边，而不会导航至侧面板或使用快速分配命令。

在Gitaly Cluster(测试版)中分发读取

Gitaly Cluster允许在多个热Gitaly节点上复制Git存储库，从而通过消除单点故障来提高容错能力。

在GitLab 13.1中，可以在最新的Gitaly副本之间分配Git读取操作。这样可以更好地利用可用资源，并可以提高性能。

为了评估其在生产负载下的性能，此功能将作为Beta发布 。

默认情况下启用了Gitaly Cluster自动故障转移

Gitaly Cluster通过消除单点故障，检测故障并自动切换到副本来提高GitLab中Git存储的容错能力。在GitLab 13.1中，配置了Gitaly Cluster后，默认情况下会启用SQL管理者选举和自动故障转移。

如果在故障转移期间检测到未复制的写操作，则群集将进入只读模式以防止脑裂。将来，强大的一致性将要求在多个Gitaly节点上成功执行写操作，然后以成功信号进行响应，从而避免了此问题以及将群集标记为只读的需要。

在以前的GitLab 13.0中，默认情况下管理者选举是默认的，而不是自动故障转移。

在静态站点编辑器中链接和预览图像

静态网站编辑器在编写Markdown内容时提供即时的视觉反馈，并提供直观的格式控制以确保一致且准确的标记。GitLab 13.0中引入的这种视觉编辑体验仅限于文本内容。

在GitLab 13.1中，可以使用"静态站点编辑器"将图像快速添加到页面中。单击格式栏中的"图像"图标后，只需链接到URL，添加可选的ALT文本，即可完成操作。链接可以引用项目中已经托管的图像，内容交付网络外部托管的资产或任何其他外部URL。编辑器将呈现缩略图预览，以便可以验证是否包含正确的图像，并且没有对丢失图像的引用。

Web IDE终端和文件同步迁移至Core

GitLab 11.6引入了用于Web IDE的Web终端。几个版本以后，添加了文件同步到Web终端，使Web终端可以与Web IDE中所做的更改进行交互。

在新版本的GitLab中，完成了将Web Terminal和File Sync工具移至Core的工作，免费给CE版本。

修改后文件优先测试(PREMIUM及以上)

作为开发人员，希望快速获得有关更改的反馈，包括新编写的测试的结果。在像GitLab这样的大型项目中，要等待45分钟才能看到新的单元测试通过，或者甚至失败，等待时间可能特别困难。这种缓慢可能导致完全跳过自动化测试开发。

Ruby开发人员可以使用TestFileFinder gem来查找针对修改后的代码的测试，然后在管道的早期阶段运行这些测试，从而缩短反馈周期。这是一种解决问题的。

使用元数据来了解如何构建NuGet软件包(PREMIUM及以上)

当NuGet软件包上传到GitLab时，作业将打开存档并读取.nuspec文件。包名称和版本被提取，但其他一些领域，如dependencies，project_url和tags也有，但不提取。这些字段对于了解如何构建软件包及其依赖关系很有用。

在GitLab 13.1中，将提取此元数据作为上载的一部分并将其包含在用户界面中，以便验证软件包是否已正确构建。

多个功能标志策略的API设置支持(PREMIUM及以上)

现在，可以创建功能标记策略，并通过公共API将其应用于环境。以前，策略是绑定到环境的。引入新策略需要定义其他环境并将其附加到这些环境。这个新的API将允许定义与环境无关的策略。

产品内链接到用于部署到AWS的指南

设置AWS部署并不总是希望的那样容易。为了使更轻松地使用AWS功能，当开始添加AWS CI/CD变量时，Gitlab已将产品内链接添加到AWS模板和文档中。这些链接应该可以帮助用户更快地启动并运行。

指定发布链接的资产类型

新版本中，GitLab允许使用下拉菜单方便地指定已添加到发布中的资产链接的类型。以前，如果添加了到发行版的链接，则无法传达它是什么类型的资产。使用此添加项，可以从以下选项中选择资产类型：" Runbook"，" Package"，" Image"或" Other"。

集成Terraform的简化设置

可以使用GitLab提供的Terraform镜像更轻松地运行GitLab集成的Terraform功能。GitLab Terraform镜像通过包含简单的命令来使用合并请求小部件，而不会扩充的CI/CD YAML文件，从而扩展了Terraform版本0.12和0.13 beta的官方Terraform镜像。

改进了对GitLab管理的Terraform状态的授权

GitLab 13.0中引入了已知限制的GitLab管理的Terraform状态：需要提供个人访问令牌才能使用状态文件。此选项无法很好地扩展。

从GitLab 13.1开始，将使用代理用户的凭据扩展了自动生成的CI令牌的范围。该令牌专门用于运行Terraform状态管理作业，从而使用户能够安全地运行Terraform作业管道，而无需进行任何其他设置。

状态页显示图像(ULTIMATE)

现在可以渲染发布到问题描述中包含的图像，从而为客户，用户和利益相关者提供有意义的上下文，以帮助他们做出有关如何处理中断和性能下降的决策。与文字共享视觉效果可以提高透明度，从而提高用户的信任度和信心。

新的Geo Disaster Recovery命令用于故障转移预检(ULTIMATE)

使用GitLab Geo执行故障转移时，系统管理员应在将辅助节点升级为主节点之前执行许多预检检查，以确保故障转移成功。这些例行检查中的许多检查都需要手动进行的，因此增加了人为出错的机会。GitLab 13.1中，Geo引入了一个新命令：

gitlab-ctl promotion-preflight-checks

该命令会列出了所有必需的转移前检查，并要求系统管理员确认已执行这些检查。该命令在运行时会自动运行：

gitlab-ctl promote-to-primary-node

缩小高级全局搜索中的索引大小(STARTER及以上)

在以前的GitLab版本中，高级全局搜索索引过程通过将所有部分单词的列表存储在索引中来支持部分匹配。部分单词为自然语言搜索查询提供更好的结果，但是执行代码搜索的用户经常搜索特定的文本，例如函数定义。

GitLab 13.1中已禁用了代码的部分匹配，从而将索引大小减小了75%。如果需要，用户可以通过在代码搜索查询中使用通配符来继续使用部分匹配。仍然支持其他内容类型的部分匹配，例如问题或合并请求。

启用"高级全局搜索"的自助客户必须在更新后重新编制索引，让生效索引大小的减少。

将IAM角色用于加密的Amazon S3存储桶

现在，可以使用AWS IAM角色来访问加密的S3存储桶。以前，加密的S3存储桶根本无法工作。

Omnibus的改进

在GitLab 13.1中，处理了一些N+1数据库调用，结果响应时间缩短40%。范围搜索变得非常快捷。

GitLab软件包现在可用于Raspbian Buster。要在Raspbian Buster上下载并安装GitLab，请访问其安装页面。

新文档已添加到"数据库设置"页面，以说明如何升级外部PostgreSQL数据库。

Omnibus GitLab中捆绑的NGINX版本已从1.16.1更新到1.18.0。

用于签署GitLab Omnibus软件包的GPG密钥的有效期已延长至2021年7月。如果为安装验证了Omnibus软件包的签名，则还必须更新签名密钥的副本。

请注意，此密钥与2020年4月更新的存储库签名密钥是分开的。有关如何更新密钥的说明，请参阅Omnibus的有关文档。

GitLab 13.1 打包了Mattermost 5.23，这是开源的Slack替代方案。最新版本功能包括自动链接到Jira问题、安全更新等，建议从早期版本升级。

Omnibus GitLab用户的自我监控仪表板

在GitLab 13.1中，Omnibus GitLab用户将在自我监视项目中拥有一个全新的现成仪表板，以监视其GitLab实例的运行状况。

GitLab Runner 13.1

同期还发布了GitLab Runner 13.1。GitLab Runner是一种轻量级，高度可扩展的代理，可运行的构建作业并将结果发送回GitLab实例。GitLab Runner与GitLab CI/CD结合使用，GitLab CI/CD是GitLab附带的开源持续集成服务。

新功能：

GitLab Runner Windows Docker Executor支持Windows 1903和Windows 1909；

提供用于RHEL/CentOS 8的软件包。

运行作业响应中定义的任何步骤。

Kubernetes执行器支持私有注册表的Docker授权配置。

GitLab Helm chart改进

新版中GitLab Helm图表中支持该extraEnv模式。这使您可以为特定的GitLab图表或全局为所有GitLab图表公开其他环境变量，例如代理服务器。

所有GitLab子图deployment中values.yml都提供了在全局设置中的部分中配置的自定义注释。部署批注允许您在部署级别而不是节点级别授予访问权限，例如，允许部署读取Amazon S3存储桶而不必授予整个节点对该存储桶的访问权限。有关如何设置部署注释的详细信息，请参见注释文档。

GitLab容器映像中的PostgreSQL库和客户端已更新到PostgreSQL 12，以允许使用更多版本的PostgreSQL。请注意，GitLab 13.1仍仅支持PostgreSQL 11，但计划在将来的发行版中支持PostgreSQL 12 。

为了提高安全性，现在可以在配置注册表通知时为敏感的标头值(例如端点的授权令牌)传递Kubernetes机密。

安全和审计

将可选的expires_at参数添加到/user /keys接口

用户API 的/user/keys和/users/:id/keys接口现在支持可选的expires_at参数，以定义SSH密钥的到期日期。此更改可以帮助用户和组织在受监管的环境中管理凭过期。

Audit Events API添加了项目接口(STARTER及以上)

GitLab的Audit Events API已扩展，可以为项目添加一个接口，从而让组所有者可以轮询API以获取特定的项目级数据。这项更改使查找和检索管理合规性程序所需的数据变得更加容易，并且为实现GitLab项目的可审核性和可追溯性构建了所需的工具。

IP访问限制(PREMIUM及以上)

IP访问限制现在适用于Premium和Silver层。此功能使可以通过一个或多个IP子网限制对组及其基础内容的访问。启用IP访问限制可确保特定内容不会离开房屋，同时不会阻止对整个实例的访问。

从组安全性仪表板导出漏洞列表(ULTIMATE)

现在，可以从"组安全性仪表板"中下载一个CSV文件，其中包含针对组中所有项目检测到的漏洞。然后，此导出列表可用于创建合规性报告或用作外部仪表板的数据源。这具有从"实例" 和"项目安全性"仪表板导出报告的功能。

只需转到任何组安全性仪表板，然后单击新的"导出"按钮即可。浏览器将自动开始下载。

更出色的面面检测和新的独立密码检测模板(ULTIMATE)

密码检测已从SAST的子功能提升为它自己的类别。现在，"密码检测"发现更加可见，显示在合并请求和管道安全性选项卡中的自己的部分中。现在，"秘密检测"还将在"安全性配置"页面上显示配置状态，并在"项目安全性仪表板"中显示发现。

密码检测CI/CD配置设置在单独的GitLab提供的模板中提供，并作为新的安全扫描类型运行。Auto DevOps现在也包含了这个新的密码检测模板。建议实施此新模板，然后从文件中的SAST配置模板中删除旧的SAST secrets-sast作业定义。以后的GitLab版本中弃用旧的SAST秘密作业定义SAST.gitlab-ci.yml。

SAST扫描舵图(ULTIMATE)

针对Kubernetes清单的已更新，支持Helm Charts。此更新还增加了对两个新环境变量KUBESEC_HELM_CHARTS_PATH和KUBESEC_HELM_OPTIONS的支持，以自定义分析仪设置。

容器网络策略的策略管理(ULTIMATE)

使用用于容器网络策略的策略管理UI的第一版，用户可以轻松扫描项目中部署的网络策略列表，并通过GitLab的UI启用或禁用这些策略。可以在"安全性与合规性" ->"威胁管理"->"策略"中找到新的策略管理经验。

通过API创建新的SSH密钥时添加了审核事件(PREMIUM及以上)

现在，通过用户或管理员通过API为用户创建SSH密钥后，现在将在审核事件表中看到该操作记录。此前这些操作没有记录下来，因此在用户的SSH凭据的可审核性方面造成了空白。

贡献分析现在显示批准(STARTER及以上)

贡献分析可帮助团队了解如何平衡许多参与者的工作量。到目前为止，尽管合并请求批准者在确保合并请求获得适当级别的审核中发挥了重要作用，但它们的贡献仍被忽略。现在，每个组成员的捐款表都包括一个可排序的已批准MR列表，可以按已完成的批准数量显示审批者。

组成员资格允许列表支持多个电子邮件域(PREMIUM及以上)

在GitLab 13.1中，所有者现在可以将组成员身份限制为具有多个域而不是单个域的电子邮件地址的用户。这个新的配置选项将为您提供更大的灵活性，同时确保对分组访问。

安全仪表板上的动态问题状态图标(ULTIMATE)

以前，在"安全性仪表板"中，具有相关问题的漏洞列表项显示一个带有该问题链接的静态图标。通过改进可用性，该图标现在可以动态反映问题是打开还是关闭。一目了然，您现在可以判断是否可能需要进一步关注漏洞。

在安全仪表板上保留筛选器(ULTIMATE)

GitLab 13.0引入了独立的漏洞页面，这是迈向漏洞管理未来的重要一步。但是，从弹出信息框切换到独立页面带来了一些新的UI注意事项。

从"安全性仪表板"导航到漏洞页面，然后又返回以前，清除了在仪表板上应用的所有过滤器。为了改善这种体验将改善漏洞分类和管理体验，新版本中在漏洞页面和仪表板之间移动时，过滤器将保持存在，从而大大提高了管理漏洞的效率。它还与在GitLab的其他地方发现的熟悉的UX模式匹配，例如管理待办事项列表。

Rails SAST分析器适用于所有

静态应用程序安全测试(SAST)通过允许开发人员在编写代码时轻松识别常见的安全问题并主动缓解它们，从而帮助防止了安全漏洞。作为对社区管理承诺的一部分， GitLab将免费Rails SAST分析仪(Brakeman)。所有Rails开发的GitLab用户都可以在项目中利用SAST安全扫描。后面将继续将会陆续开源其他(OSS)SAST分析仪。

Bug修复

13.1中一些值得注意的BUG修复有：

如果通过UI创建发布，则不会收集GitLab发布证据；

图片在发布列表面板中溢出；

版本说明中的Markdown格式未正确显示；

显示上游管道中的下游管道错误；

尝试通过Jobs API下载标记引用的工件存档失败，并显示" 404 Not Found"；

验证实例级别变量的值的大小；

在禁用管道，合并请求"必须成功"选项处于启用状态并且禁用了外部管道时，显示准确的错误消息；

搜索提交时遵从"ref"参数；

确保设置Elasticsearch highlight.max_analyzed_offset整个GitLab应用程序中参数；

修复Elasticsearch版本7.7.0的嵌套数组问题；

将机密问题中的注释显示为机密注释的bug；

在Epic树中显示通过API添加到Epic的问题；

通过API按标题添加时，按顺序应用范围标签；

NOT为Epics 启用布尔过滤器；

性能改进

在GitLab 13.1中，提供了CI管道处理，查看git blame等方面的性能改进。GitLab 13.1中的性能改进有：

对blame文件延迟加载加载提交日期和创作日期；

当查看文件时缓存内容；

优化的CI管道处理；

功能弃用

作业的默认存档时间设置为3个月

变更日期：2020年6月22日

为了帮助使用gitlab官网的所有工作存档日期将设置为3个月。作业存档后：可以对归档作业执行的操作和不能执行的操作如下：

仍然可以查看作业，日志，关联的管道和部署，以及重新运行整个管道。

无法重试，重新运行或触发该作业，也无法触发该作业的部署。

2020年3月22日之前生成的现有作业将在2020年9月22日之前存档。

默认工件过期在gitlab.com上更改为30天

变更日期： 2020年6月22日

为了帮助维护使用gitlab官网整体性能，管道工件的到期时间将在被设置为30天。在更新的作业生成新的工件后的30天之前，将不会归档来自上一个成功作业的工件。没有到期日期的工件不会更改，但是以后的更新也会为其添加到期日期。

AWS ECS的部署模板正在移至新位置

变更日期： 2020年7月22日

更改了Deploy to AWS ECS gitlab-ci.yml模板的位置。如果用户已在CI/CD配置中引用了此模板，请通过替换template: Deploy-ECS.gitlab-ci.yml为对其进行更新template:AWS/Deploy-ECS.gitlab-ci.yml。目前正在扩展受支持的AWS目标，并且所有将来与AWS相关的模板都可以在AWS template文件夹中找到。

在SAST配置中弃用秘密检测作业

变更日期： 2020年9月22日

新版本中，密码检测CI/CD配置设置被挪到一个单独的GitLab模板中，并作为新的安全扫描类型运行。为确保项目继续运行密码检测，建议使用新的秘密检测模板，然后从文件中的SAST配置模板中删除旧的SAST secrets-sast作业定义。

GitLab 13.4即将取消对旧的SAST秘密作业定义的支持。

Auto DevOps弃用Herokuish支持

变更日期： 2020年10月22日

GitLab正在将Auto DevOps从Herokuish buildpack迁移到Cloud Native Buildpacks，Herokuish将从根本上弃用，Cloud Native Buildpacks是buildpack支持的下一个迭代。

GitLab 12.10及更高版本将支持Cloud Native Buildpacks。所有新的Auto DevOps项目将于下个月开始使用Cloud Native Buildpacks，Herokuish支持将在2020年10月取消。

不建议使用Kubernetes 1.12和1.13进行集成

变更日期： 2020年9月22日

为了将Kubernetes与GitLab集成，Gitlab引入了Kubernetes支持策略，为Git用户提供明确的升级时间表：

GitLab对Kubernetes 1.12的支持将于2020年9月22日终止。

GitLab对Kubernetes 1.13的支持将于2020年11月22日终止。

在这些变更之后，各种GitLab功能可能仍然可以使用，但是将不会得到官方支持。GitLab同时致力于增加对最新Kubernetes版本的支持。

Kubernetes 1.12已被弃用

变更日期： 2020年8月22日

从GitLab 13.2开始，Kubernetes 1.13将成为部署GitLab时受支持的。Kubernetes 1.12 不再在上游维护，最近已被流行的容器管理服务(如GKE和EKS)删除。

旧功能标志弃用

变更日期： 2020年9月22日

在13.1之前创建的功能标志与正在开发的新体系结构不兼容。从13.1开始，默认情况下，GitLab在线仓库将启用新系统创建所有新功能标记。从13.2开始，对于自建实例也是生效。在早期版本中创建的功能标志可以使用到13.4，然后它们将变为只读。在14.0中，所有旧版功能标志将被完全删除。

Git 2.25或更高版本

变更日期： 2020年6月22日

从GitLab 13.1开始，GitLab需要Git 2.25或更高版本。Omnibus安装包括Git 2.27。从源安装的实例必须手动升级。

计划删除安全扫描程序的Docker-in-Docker(DinD)

弃用日期： 2020年9月22日

为了提高安全性并降低扫描的复杂性，在13.0中已弃用GitLab Secure扫描器中的Docker-in-Docker(DinD)，并计划在13.4中将其删除。默认情况下，GitLab安全产品开始在GitLab 13.0中的供应商模板中使用非DinD模式。Gitlab鼓励用户更新其供应商的模板以使用此新行为。如果您覆盖或使用自定义Secure CI模板，则可以按照以下指南从现有作业模板中禁用Docker in Docker(DinD)：

在Docker中禁用Docker进行依赖性扫描(12.10文档)

在Docker中为SAST禁用Docker(12.10文档)

升级更新

Omnibus安装

Omnibus套件安装的实例可直接使用Linux包管理器可以升级。

比如CentOS使用:

yum updata/install gitlab-ce

即可自动完成升级：

docker安装

先停止和删除旧的容器：

sudo docker stop gitlab

sudo docker rm gitlab

拉取官方最新镜像：

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.1的重要说明

Gitaly中服务器端Git hook使用的配置值存储在中gitlab-shell/config.yml。新版本中存储在Gitaly的config.toml文件中的[gitlab]和[hooks]TOML部分。

在升级到GitLab 13.1之前，您必须升级到GitLab 13.0，或者-如果您正在使用Helm图表安装，则必须升级到该图表的4.0版本。

对更老版本升级，请遵循以下路径：