日前，Gitlab发布了新的月度版本13.3。本次版本的核心在于通过DevSecOps帮助团队在软件开发过程的早期检测并解决故障和漏洞。GitLab 13.3中，新增加了在开发流程中的模糊测试使构建安全软件更加容易。通过覆盖率指导的模糊测试和按需DAST可以更快更及时的发现软件漏洞。同时，使用新的CI/CD构建矩阵，可以更轻松地更频繁地释放代码。更多功能请和虫虫一起学习。

概述尽早发现并预防缺陷和漏洞

通过覆盖率指导的模糊测试，现在可以更有效地浮出水面并解决C，C++和Go中的漏洞。在GitLab 13.3中，所有的SAST（静态应用程序安全测试）分析器全部开放，也支持从GUI运行DAST。更重要的是，安全人员可以利用DAST输出中包含的新漏洞证据来更快地解决漏洞。

减少周期时间，更频繁地发布

借助新的构建矩阵，可以轻松构建强大的工作流：一次定义键和值，多次发布和部署。团队可以通过测量MR Analytics仪表板中现在提供的合并请求吞吐量来提高速度。在合规性仪表板上追溯对MR中不同角色所履行的职责的确认。维护者还可以向其贡献者建议一个壁球提交策略。最后，使用新命名的功能标记策略，可以更加有针对性地控制发布。

交付团队更加高效和高效

软件开发主要是关于构建和分发软件包。为了简化操作并考虑到可用性，新版本对整个Package注册表GUI进行了全面改进，并且对外免费开放。另外，以自动化的方式发布NuGet软件包可以简单使用。部署后，团队将无需担心系统的运行状况。现在可以根据Pod运行状况仪表板上的信息采取所有相关措施。

GitLab 13.3主要功能适用于Go和C/C ++应用程序的覆盖率指导的模糊测试（ULTIMATE）

新版本中可以对Go和C/C ++应用程序运行覆盖率指导的模糊测试。这是查找其他安全扫描程序和传统质量检查人员可能会错过的安全问题和错误的好方法。覆盖率指导的模糊测试使用有关的应用程序的上下文信息来随机生成输入，并查找崩溃或其他错误，然后在它们影响生产中的用户之前进行修复。

这是第一个结合了模糊测试收购中的新技术的版本。

使用简单的语法创建作业矩阵

GitLab的子/父管道可以自定义代码以生成整个管道YAML。这是生成自定义行为的强大方法，包括在运行时生成作业。对于只想为一组定义的案例创建多个相似作业的简单场景，可能不需要这样做。在新版本中，可以找到一个新matrix关键字，该关键字可与parallel一起处理为创建多个作业的工作，每个作业具有不同的变量。

例如，可以将管道配置为自动为4种不同的体系结构创建作业，每个体系结构都具有debug和release目标3种不同的版本，所有这些都具有单个矩阵样式的配置。这将创建24个唯一的作业（4x2x3），以覆盖所有可能的组合。

合并请求批准显示谁参与了审核（STARTER及以上）

代码审查通常涉及多个人和多个迭代。关于审核相关信息很重要，比如谁审核，哪些MR审核通过，哪些还未批准等，清楚了解这些信息可以避免重复工作和浪费时间。

为了显示谁通过注释提供了反馈，合并请求小部件现在显示"Commented by"列。这使作者和审查人更容易确定参与人员。

在功能标志列表视图中显示策略信息（PREMIUM及以上）

通过在GitLab 13.0中引入对每个功能标记的多种策略的支持，可以为功能标记设置策略。但是，无法在功能标志的列表视图中看到相关的策略信息。现在可以在列表视图中查看有关功能标记的所有相关信息，包括策略，环境以及启用了该标志的用户数或百分比。此视图使可以快速了解项目中所有标志的配置，而无需单独打开每个标志。

外部服务的实例级项目集成管理

自建的GitLab实例管理员新版本中可以通过单个界面将第三方服务与实例上的所有项目集成在一起。

以前，必须针对每个项目配置集成，这意味着，如果一个实例具有数千个项目，则必须手动配置数千个单独的配置。不仅很耗时，而且还容易出错，难以更新，并且很难将集成作为策略来实施。

通过在所有项目之间配置集成，管理员可以节省自己和项目所有者的大量时间和精力。

这次发布的是该功能的第一次迭代。在即将发布的版本中，该功能扩展到组级别，添加更多配置和合规性选项，等等。

在GitLab中创建和管理IT事故

调查事件需要呼叫工程师评估多种工具中的不同数据源。评估指标，日志和跟踪，共享发现并工程师需要通过屏幕抓取，复制和粘贴来手动汇总信息。这项工作效率低下且耗时，导致警觉疲劳，增加工程师压力，使其士气低落。

在13.3中， GitLab的"运维"部分中引入一个用于分类和管理事件的专用列表，以帮助减少解决时间。"事故"列表提供了事件的高级摘要以及关键的详细信息：创建事件的时间，分配的人以及状态页的发布状态。此外，根据状态（打开，关闭和全部）还可以组织不同的视图，从而可以轻松识别活动事件。

在GitLab 13.4及更高版本中，计划通过显示相关的度量图表，嵌入日志并呈现关联的运行手册来改善事件响应工作流程。要查看进度并为将来的改进提出建议，

包注册表现在在Core中可用

一年半以前，通过直接在GitLab中构建Maven支持来扩展了对Java项目和开发人员的支持。其目标是提供一种标准化的方式来共享软件包并在项目之间进行版本控制。在与客户和社区合作的同时，进一步投资建立了Package团队，以更好地了解用例。还添加了对Node，C#/.NET，C/C++，Python，PHP和Golang开发人员的支持。对这些功能的采用，使用和增加的投入，使能够将视野扩展到更全面的解决方案，并集成到单个应用程序中，该应用程序支持所有常用语言和二进制格式的软件包管理。没有GitLab社区的明确支持，就不可能实现这个目标。

作为GitLab管理承诺的一部分,GitLab Core Edition中现已提供每种软件包管理器格式的基本功能。如果使用npm，Maven，NuGet，Conan，PyPI，Composer或Go模块，将支持：

使用GitLab作为私有（或公共）软件包注册表

使用的GitLab凭据，个人访问权限或工作令牌进行身份验证

将软件包发布到GitLab

从GitLab安装软件包

搜索托管在GitLab上的软件包

访问易于使用的UI，该UI显示软件包详细信息，元信息，并允许下载任何相关文件

确保贡献可用于所有GitLab用户

适用于Visual Studio Code的GitLab工作流程扩展现已正式发布

两年前，Fatih Acet创建了一个扩展，以将GitLab与Visual Studio Code中的开发集成在一起。Fatih和25个以上的贡献者继续通过新功能改进扩展，现在已安装了160,000次。Fatih将维护权限移交给了GitLab，GitLab将继续改进和支持此扩展。

GitLab工作流程现在由GitLab官方正式维护和支持。将继续贡献功能，并为积极参与早期发行版的社区提供支持。

在父项目中为派生的MR运行管道（STARTER及以上）

作为项目维护者，可能希望启用自己的项目的CI CD管道进行了全面测试的分支项目的贡献。以前，必须向贡献者提供项目CI运行器，CI配置和CI变量的访问权限，这是许多开发小组都不愿意做的事情。现在，GitLab允许具有适当权限的父项目成员为使用父项目的CI / CD配置从派生提交的MR运行管道。它还显示一个警告对话框，说明在启动管道之前的风险，以便可以更好地缓解潜在风险。

来自本地JSON的ECS任务定义

如今，GitLab的ECS部署模板更新了已在附加的AWS账户中定义的现有任务定义。在GitLab流程中更新任务定义也很常见。现在，可以在本地存储库中更新JSON任务定义，并在知道该任务将在AWS账户中正确创建的情况下推送它，从而改善标准开发流程。

项目访问令牌

项目级访问令牌允许访问项目，而无需提供GitLab用户。项目访问令牌可以由项目维护者或所有者生成，并用于通过GitLab API进行身份验证。项目访问令牌将被授权为维护者。这项新功能将使对GitLab的编程访问变得更轻松，更安全且成本更低。

有向无环图（DAG）管道的可视化

可能已经注意到管道上新的DAG选项卡，该选项卡使用关键字直观地呈现了管道的有向无环图依赖关系needs。这使更容易理解CI/CD配置中的复杂依赖关系网。在新版本中，该功能被已正式发布，并且正在删除beta标签。

从UI编辑功能标志用户列表（PREMIUM及以上）

现在，可以直接在UI中创建，编辑和删除功能标记用户列表。以前，只能通过API执行这些操作。快速，轻松地将用户添加或删除到列表中，以及更改列表名称。

合并请求的多行注释

对合并请求差异中的行注释是一种为作者留下反馈的好方法。审查者通常需要对代码的整个部分进行注释，例如，覆盖多行代码的函数或表达式。在引用多行的同时，在一行上留下评论会使通信不清晰和效率降低。

通过引入多行注释，审查者将不再需要决定在审查期间选择哪一行代码，而是可以向合并请求差异中的多行提供反馈。

合并请求分析（STARTER及以上）

包括GitLab在内的许多组织都使用吞吐量来衡量团队的工作速度。新版本中引入合并请求分析的第一个迭代，以帮助的团队更好地了解项目中合并MR的比率。

合并请求分析可在项目级别使用，可以帮助工程团队快速了解MR活动。对更详细外观感兴趣的用户（例如，对具有特定标签的MR感兴趣的团队负责人）还可以过滤并查看相关MR的详细列表。

禁止额外Fork

新版本中，组管理员可以防止其组内的项目在当前顶级组之外创建新的派生。此新设置为组管理员提供了其他机制来保护其组的知识产权。

查看合并请求时显示单个文件

在审查代码贡献时，审查合并请求差异是一项基本任务，因为这是作者与审查者之间大部分沟通的地方。但是，随着合并请求变得更大并且涉及更多文件，合并请求差异的导航和性能可能会变得困难。

为了解决这个问题，GitLab 13.3引入了一个选项，可以在合并请求的"更改"选项卡上一次查看一个文件。它提供了更整洁的工作空间，并增强了审阅者对单个文件的关注。在底部，可以通过单击Prev和Next按钮在更改的文件之间导航 。可以通过用户首选项有选择地启用它。

拖放以重新排序设计

如果使用GitLab设计具有屏幕或用户流程的产品，则需要按特定顺序放置设计，以向团队展示完整的概念。

以前，设计仅按它们上载的顺序显示，从而使评论复杂化并导致沮丧。

从13.3开始，现在可以将设计拖放到任何顺序中。将保存顺序，以便查看设计的任何人都可以看到想要的顺序。继续创建想像的流程或重新排序以匹配Figma或Sketch中的帧。

代码提示

代码审查是一个重要的过程，需要了解建议的更改和周围的代码，以了解是否已以可维护的方式进行。GitLab的本机代码提示可帮助开发人员浏览代码并了解合并请求中引入的更改。这对于理解现有代码也很重要，以确保以负责任的方式添加新代码。

GitLab 13.3引入了使用GitLab的本机代码提示显示项目引用的功能。单击代码中的对象将显示定义，并提供在第二个选项卡上浏览引用的功能，并显示使用该对象的完整路径和行号。

未来的迭代将包括API支持，并在弹出窗口中显示引用代码。

CI/CD组变量的审核日志（STARTER及以上）

当无法跟踪CI/CD变量的更改时，很难理解是什么原因导致了管道失败。现在，在变量审核日志的第一次迭代，可以跟踪对组级CI/CD变量的更改。新的审核日志捕获三个事件：组变量添加，删除和受保护状态更改。

CI linter提供除错误之外的警告

现在，CI linter可以在验证.gitlab-ci.yml文件时提供除错误消息之外的警告。这使有机会在评估管道时提供更多指导，从而更容易通过尽早发现错误来避免发生更多类型的错误。

初始迭代是在when:always不使用规则的情况下提供警告workflow:rules；创建MR时，这种情况会导致重复的管道，并且也引起了混乱。而且，除了在linter页面上显示此新警告消息外，它还将显示在管道视图和运行管道页面上，以帮助改善CI配置。

配置作业工件以永不过期

作为开发人员，可以指定作业工件的确切到期日期，但是在某些情况下，可能需要永久保留工件。现在，可以通过在CI配置中设置expire_into的值为never来将工件设置为永不过期。

改进失败快速测试模板（PREMIUM及以上）

在GitLab 13.1中引入了Fail Fast Testing模板，并收集了利益相关者的反馈。发现，如果默认镜像在.gitlab-ci.yml文件中被覆盖，则该模板将无法工作。此后，改进了Fail Fast模板，因此即使指定其他镜像，也可以信任Fail Fast模板立即使用。

查看和管理小组Runner

添加了一个新的组管理用户界面（UI），用于管理组织的运行者。在此新用户界面中，可以在GitLab中查看，编辑，暂停和停止与组关联的任何Runner。这样可以更轻松地一次解决多个项目的Runners潜在问题。

使用CI作业令牌发布NuGet软件包

可以在源代码和CI/CD管道旁边使用GitLab NuGet存储库来构建，发布和共享.NET软件包。但是，此前无法通过使用预定义的环境变量CI_JOB_TOKEN来对存储库进行身份验证。结果，被迫使用个人凭据来更新NuGet存储库，或者不使用存储库。

现在，使用GitLab CI/CD使用预定义的CI_JOB_TOKEN环境变量来发布和安装NuGet软件包比以往更加容易。

重新生成功能标志实例ID之前的确认对话框（PREMIUM及以上）

当实际上打算复制实例ID时，很容易意外地为功能标记重新生成实例ID。如果实例ID重新生成，则需要在应用程序中对其进行更新，然后在所有环境中重新启动该应用程序。现在有一个确认步骤，要求在重新生成ID之前键入项目的名称。这将大大降低意外生成ID的风险。

查看任何用户均可访问的应用程序链接

直到现在，如果不是最初创建MR的各个项目的成员，就无法在"合并请求"中看到"查看应用程序"链接。在13.3中，使任何用户都可以使用审阅应用程序，从而使可以从任何人甚至客户那里获得有关代码更改的反馈。通过允许每个人都做出贡献，可以更好地协作并缩短反馈循环。

使用Webhooks跟踪GitLab中的部署事件

GitLab通过支持成功，失败和已取消部署的Webhook使更轻松地构建部署自动化。

将运行手册添加到Gitlab警报

当事件发生时，如果值班工程师没有编写导致事件的代码，则很难知道如何响应。拥有运行手册或有关导致警报的度量标准的知识，对于确定问题的根本原因并快速解决问题至关重要。现在，可以将运行手册添加到在GitLab中配置的警报中，以便触发的警报为的值守团队提供解决问题所需的步骤。

以量规格式显示指标仪表板数据

在监视仪表板上引入了仪表盘图作为新的可视化选项，以显示单个指标的渐进值。

将警报从GitLab管理的Prometheus链接到日志

对警报进行分类时，没有时间可以浪费：必须迅速进行调查，而无需上下文切换。GitLab 13.3通过从警报的"度量"选项卡中的图表链接到度量的日志来节省的时间。

在列表视图中按状态组织事件

在跨多个事件协调响应团队时，了解哪些事件是公开的，并需要立即关注，哪些事件已解决和关闭是非常重要的。GitLab 13.3现在按状态将事件分开，并将其组织到选项卡中，从而帮助专注于相关的开放事件。

更快呈现丰富内容

用户在GitLab UI中执行的常见任务之一是查看丰富的内容，例如问题中的渲染降价，合并请求或仅查看文件。对于大内容，这可能需要很长时间才能完成，从而导致漫长的等待时间。

在GitLab 13.2中，优化了此内容的生成方式，从而改善了用户体验并减少了服务器上的负载。！

现在，在Slack之类的工具中可以取消搜索结果的链接

在诸如Slack之类的工具中展开URL可为其他团队成员提供有用的上下文。在GitLab 13.3中，搜索结果页面具有更新的元标题，以便在展开时提供更好的描述。

PostgreSQL 12

PostgreSQL 12现在作为可选的PostgreSQL版本受支持，用于GitLab的自我管理安装。PostgreSQL 12包括许多性能上的改进，例如针对大型数据集的改进的查询性能。

创建多个自定义值流（PREMIUM及以上）

在新版本中，允许团队创建多个自定义价值流，从而使可定制的价值流分析（VSA）更加出色。VSA中的可自定义性使团队可以对小组的活动有详细的了解，并且现在可以在此功能中创建和重用自定义阶段，而无需每次都重新创建它们。

这是跨多个部门进行协作的项目和小组的理想选择，其中每个部门可能会以不同的方式衡量价值。项目经理可能希望查看由问题标签定义的价值流，但是工程团队可能希望了解合并请求活动和部署时间。有了多个价值流，现在就可以为两个创建和自定义单独的价值流。

禁用未知登录电子邮件通知的选项

已改进了未知登录电子邮件通知的逻辑，以使用户收到的电子邮件更少。建议启用未知登录电子邮件通知，但GitLab管理员现在还可以选择为其实例禁用未知登录电子邮件通知。如果用户无法在其浏览器中接受cookie并且用户的IP经常更改，则可以使用此选项。

在所见即所得静态网站编辑器中显示非MD内容

静态站点生成器通常依靠Markdown来组织内容，而Static Site Editor为这些文档提供了直观的所见即所得Markdown编辑体验。但是，它们的内容并不总是用Markdown编写。许多生成器支持Markdown中嵌入的其他标记，以扩展作者的功能。将HTML和markdown内容一起编写也是有效的。

静态边编辑器的WYSIWYG模式现在将非Markdown内容分成不可编辑的内容块，并与内容内联显示。这样可以防止在编辑器尝试将非Markdown内容转换为HTML时出现意外的格式错误。非Markdown内容仍可以在"静态站点编辑器"的原始源模式下进行编辑，以后的迭代将使可以在所见即所得模式下安全地编辑此类内容。

增强型Web编辑器

已将Web编辑器升级到Web IDE中的轻量级版本。这增加了某些语言的基本代码完成和填充。还改进了源代码语言检测，以更好地突出显示语法，并增加了对所有语法突出显示主题的支持。这些改进使在项目中的文件上进行编辑和协作变得更加容易。

Squash提交选项

在Git中压缩提交是一种将多个提交合并为一个提交的好方法。这对于将多个提交（可能本身仅提供很少的历史价值）分组到一个大的提交中，然后再将其推向上游非常有用。推送单个提交可提供更有意义的提交消息，并确保提交组提供了"绿色"连续集成管道。

在GitLab 13.3中，为Squassh提交添加了可配置的默认值，从而使项目维护人员可以配置选项以适合他们喜欢的工作流程。由于更改squash配置可能会引入不良行为，因此未更改新项目或现有项目的配置。

WIP合并请求已重命名为草稿合并请求

合并请求的WIP（进行中）状态向审阅者明确发出信号，表明所述合并请求尚未准备好进行合并。

为了使用更具包容性和不言自明的术语，合并请求的WIP（进行中的工作）功能已重命名为"草稿"。该术语清楚地表明，有关的MR尚未准备好进行审查，也未对正在取得的进展做出任何假设。此外，它减少了新用户，非英语使用者和不熟悉WIP首字母缩略词的人的认知负担。

现在不建议使用WIP合并请求，而希望使用合并请求草稿，但是两个术语都将受支持，直到下一个主要的GitLab版本（14.0），之后将其删除。

.gitlab-ci.yml文件更好的linting检查

在查看CI定义时，现在可以使用CI linter来更深入地进行管道处理，以验证.gitlab-ci.yml。CI linter不仅提供语法验证方面的反馈，还通过模拟管道来验证其他种类的逻辑错误和无效配置，就像在master上运行一样（实际上没有运行任何东西）。这可以帮助更快地生成正确配置的管道，并有助于避免管道通过linter但仍然无法运行的情况。

CI/CD规则：如果支持带括号的逻辑表达式

如果使用rules带有if子句的关键字，它现在将更加强大，并支持由管道处理器评估的带括号的表达式。可以使用更复杂，更有效的AND（&&）/ OR（||）表达式，使管道规则更加逻辑，强大且易于管理。

JUnit报告改进

在GitLab 12.5中引入了JUnit报告，该报告提供了在管道中运行的所有JUnit测试的视图。广泛的社区帮助确定了报告界面中的一些可读性和可用性问题，这些问题使其难以使用，尤其是在测试或套件名称超过特定字符数时。此外，在解析非常大的文件或大量文件时，页面的性能可能会变慢junit.xml。新版本中提供了一个易于阅读的JUnit报告，可以放心，即使在加载数千个测试时，管道页面也会快速加载。默认情况下，此功能不是功能标志，已在Gitlab在线仓库上为所有用户启用。

改进了包元数据和活动的表示

GitLab软件包注册表用来存储和共享各种软件包。导航到用户界面时，想快速了解软件包的构建方式和安装方法。为此Gitlab重新设计了"软件包详细信息"页面，以优先考虑最近的活动，代码片段和其他元数据。删除了包含重复数据或无用数据的两列表。

软件包详细信息用户界面的主要部分现在包括：

一个新的"历史"提要，它共享与包有关的基于时间的元数据。

安装命令和注册表设置说明。

添加"其他元数据"以捕获与时间无关的任何元数据的一种方法。这个附加的元数据部分提供了灵活性，可以包括针对不同格式的包的各种详细信息。

这一变化清楚表明，GitLab的Package Registry功能已经成熟。删除原始的Maven存储库。那时，只提出如基本的元数据name和created_date。现在，将看到如何构建包并追溯到负责哪个管道和提交。期待该产品的不断发展。

重命名功能标记用户策略（PREMIUM及以上）

为了简化功能标记策略并避免混淆，将其重命名。Percent rollout (logged in users)已更改为Percent of users并List已更改为User List。

在用户界面中设置冻结冻结

此功能扩展了在13.0中引入的设置部署冻结窗口的API功能。新版本中，从GitLab UI中，可以轻松设置无法进行部署的时间段。不再需要使用API​​来编写部署冻结或使用脚本.gitlab-ci.yml。取而代之的是，可以轻松地进入UI设置以创建重复或一次性部署冻结。

使用API​​来获取Pages域配置

新版本中，可以配置GitLab Pages通过GitLab内部API来获取项目的配置，并利用该API加快GitLab Pages守护程序的启动时间。

从PagerDuty事件创建GitLab问题

新版本中，可以从PagerDuty事件中生成GitLab问题，在触发警报时自动通知响应者，并在GitLab中集中响应。

在来自外部管理的Prometheus的警报中显示指标

当收到警报时，GitLab通过在警报中包含相关指标图表来帮助减少调查时间，从而帮助直观地查看出了什么问题。在GitLab 13.2中，引入了在警报中包括自建的Prometheus实例的指标。

手动维护事故

在维护服务的可用性和可靠性时，并不总是从警报系统中了解问题：客户报告故障，或团队成员发现异常。无论来源如何，现在都可以在"事故列表"中手动创建事物，以在了解问题时动员的响应团队。

简单，精简的Metrics仪表板控制栏

此前，仪表板操作（例如创建，编辑，复制和添加指标）分散在整个指标仪表板中。GitLab 13.3将这些项目组织到一个动作菜单中，从而简化了对仪表板管理功能的访问。

内容引用速度更快

GitLab作为DevOps的单个应用程序的好处之一是，将内容链接在一起确实很容易。支持在GitLab的所有部分中引用标签，里程碑，摘要，提交，合并请求，问题和Epic。单个内容引用数十个甚至数百个其他项并不罕见。但是，这种连通性可能会导致向用户呈现内容的延迟，因为GitLab服务器需要查找每个引用以呈现其他上下文。

在GitLab 13.3中，参考查找的性能得到了显著改善。对于具有165个引用的示例内容，它的生成速度提高了75%，而内存占用却减少了一半，显著地提高了用户体验，而GitLab服务器的负载却更少。

改进代码搜索与高级搜索的匹配（STARTER及以上）

当前用于Elasticsearch集成的代码分析器并未考虑所有代码情况。例如，如果有一个文件，a.b.c=one_two_three并且要搜索one_two_three，则搜索中不会返回该文件。在GitLab 13.3中，改进了Elasticsearch中的代码分析器，现在它在匹配带有特殊字符的搜索时更加强大。

Omnibus的改进

为了防止由于空间不足而导致PostgreSQL升级失败，并使升级体验更加流畅，GitLab现在会检查以确保有足够的可用空间，然后再使用pg-upgrade命令执行PostgreSQL升级。

现在，为PostgreSQL升级指定超时值更加容易。以前，pg-upgrade只能以毫秒为单位指定的超时值。现在，还可以指定天，小时，分钟，秒或毫秒的值，或这些值的某种组合。例如，1d2h3m4s5ms。

GitLab 13.3 引入了Mattermost 5.25 其最新版本包括用于视频会议和屏幕共享的Jitsi集成，增强的Welcomebot插件等。

该版本还包含。建议尽快从早期版本升级。

GitLab Runner 13.3

一起还发布了GitLab Runner 13.3。主要更新包括

将ENTRYPOINT脚本添加到GitLab Runner帮助器镜像。

更新Windows帮助程序镜像的已安装Git版本。

将Ubuntu Docker容器更新为Ubuntu 20.04。

Bug修复

修复使用--run-untagged gitlab-runner-13.2.0-1中最新的选项无法使用rpm /deb进行注册

修复SELinux警报：SELinux阻止gitlab-runner从tcp_socket端口443上的name_connect访问

修复运行作业时PowerShell错误

修复每个构建版本的网络：服务运行状况检查超时

GitLab Helm chart改进

现在可以在GitLab Helm图表中为上游镜像/包配置依赖项代理。请注意，当前不支持备份和还原以及从Omnibus的迁移。

配置对象存储的设置已合并，以便可以通过中的一节配置所有对象的对象存储values.yml。这是一项巨大的改进，使对象存储配置更加高效，包括能够将单个凭据用于多个S3存储桶。它还使GitLab Workhorse可以直接通过其自己的S3客户端上传文件，而无需使用预先签名的URL。

为了改进聚合，现在将Workhorse日志以JSON输出，而不是以非结构化数据的形式输出。

gitlab Geo高可用集群更新Geo更快，更易于维护（PREMIUM及以上）

Geo将数据从一个主要Geo节点复制到一个或几个Geo辅助节点。尽快将数据回填到辅助节点对于确保辅助节点不会落在后面很重要。

经过多次迭代，Geo不再需要PostgreSQL外部数据包装器（FDW）。这消除了某些数据库超时的可能性，并提高了回填操作的整体性能。此外，此更改减少了配置Geo的步骤，并使维护Geo部署更加容易。为了降低复杂性，此更改导致删除了3,823条净代码行。

并发Git存储库备份

备份可防止数据丢失事件，应定期运行，并在维护和升级之前运行。因此，GitLab具有一个gitlab-backup脚本，以便系统管理员可以备份所有内容。随着存储库数量和大小的增加，使用脚本备份存储库数据的速度将变得很慢。

脚本运行缓慢的一个重要原因是存储库是一个一个备份的。未能充分利用可用的CPU和内存资源，尤其是在有多个Gitaly节点时。添加并发性允许同时备份多个存储库，从而大大减少了备份时间。

Gitaly集群读取分布

具有大量贡献者的存储库与高度并行化的CI管道或高度可变的项目访问模式结合使用，可能导致CPU和内存使用率较高，从而降低可用性。通过分片缓解这些性能问题通常会导致预留空间过大，无法处理峰值负载。

Gitaly Cluster允许在多个热Gitaly节点上复制Git存储库，并且可以通过在最新副本之间分配读取操作来扩展性能。从GitLab 13.3起，使用Gitaly Cluster时，读取操作将自动分布在最新副本之间。与分片相比，这可以更好地利用可用的CPU和内存资源，并且可以更好地扩展。

Gitaly Cluster参考事务

Gitaly Cluster允许在多个热Gitaly节点上复制Git存储库。通过消除单点故障来提高容错能力。但是，写操作当前是异步复制的，这样从接受写操作到复制完成，GitLab服务器只有一份更改副本。

在GitLab 13.3中对Git存储库的事务性写入操作导致更改被广播到所有Gitaly节点。只有与主节点一致投票的Gitaly节点才会将更改保存到磁盘。异议节点通过异步复制同步。这样更改通常会在接受写入后写入所有Gitaly节点。但是，这不能保证，因为所有副本节点都可以对主节点投票。可以启用基于仲裁的投票（beta）来防止这种情况。

Gitaly Cluster（测试版）的事务性写入

Gitaly Cluster允许在多个热Gitaly节点上复制Git存储库。通过消除单点故障来提高容错能力。但是，由于写操作当前是异步复制的，因此GitLab服务器最初仅具有一个更改副本。

在GitLab 13.2中，可以为Gitaly Cluster启用对Git存储库的事务写操作。启用此选项并将更新推送到GitLab时，写操作将被代理到副本Gitaly节点。将使用两阶段提交协议在Gitaly节点之间协调写入操作，以便它们就存储库的新状态达成一致。当前，写事务仅限于通过HTTP和SSH Git接口推送的操作，并且不包括通过GitLab接口（如Web IDE）进行的写操作。

安全和合规性审计合规性仪表板显示更多信息（ULTIMATE）

组织需要了解其小组和项目的合规性状态。合规性的主要组成部分是合并请求。它通常是确保遵循适当策略和过程的主要控制机制。因此，要突出显示的合并请求中最重要的细节之一就是指出作者和批准人之间的职责分离。

新版本在Compliance Dashboard中，可以同时查看合并请求作者和批准者，从而可以更快地熟悉那些可能没有配置职责分离的项目。

Kubernetes Pod健康仪表板

在一处查看系统的所有指标（包括集群指标）对于了解系统的运行状况至关重要。在GitLab 13.3中，可以通过以下方式在新的开箱即用的Pod运行状况指标仪表板中查看Kubernetes Pod的运行状况，无论使用托管的Prometheus还是在集群中运行Prometheus的现有实例它到GitLab实例。在下拉菜单中选择所需的Pod，然后查看关键指标，例如CPU，内存使用情况，网络等。

按需DAST扫描（ULTIMATE）

GitLab的动态应用程序安全性测试始终专注于将DAST集成到DevOps管道中，并使开发人员能够尽早扫描其审核应用程序，运行网站或API的漏洞。但是，有时在没有进行代码更改且未创建合并请求的情况下，有必要对已部署的应用程序运行DAST扫描。

出于审核或合规性原因，调试和重现已发现的问题或支持不提交代码的团队（例如安全分析人员），可能需要这些扫描。

由于需要不由代码更改或MR触发的DAST扫描，因此现在可以按需进行DAST测试。不需要配置文件或代码即可开始运行按需扫描。

GitLab UI中提供了按需DAST扫描的配置选项。结果是更快的配置并大大提高了易用性。当开始新的按需扫描时，可以从包含首选设置的站点配置文件中进行选择。

在13.3中，发布了按需扫描的第一个迭代。这些扫描最初将限制为60秒的间隔时间和被动DAST扫描。此扫描将提供正在扫描的站点的快速侦查类型的概述，而不会引起任何性能或安全性问题。在接下来的几个版本中，将为"网站"配置文件添加选项，并介绍"扫描仪"配置文件。这些新增功能将使能够延长搜寻时间，验证目标站点的所有权，启用活动扫描，设置身份验证选项等。结果是更快的配置并大大提高了易用性。当开始新的按需扫描时，从包含首选设置的站点配置文件中进行选择。

SAST安全分析器可用于所有

为了更好帮助开发人员编写更好的代码，而不必担心常见的安全错误。静态应用程序安全测试（SAST）通过允许开发人员在提交代码时主动识别常见的安全问题并主动缓解，从而帮助防止了安全漏洞。作为社区管理承诺的一部分，gitlab已提供了全部15种基于开源的SAST分析仪。这样，所有使用18种支持的语言和框架进行开发的GitLab用户都可以在其项目中利用GitLab SAST。

使用新的指导性SAST配置经验，启用Auto DevOps或将SAST配置模板添加到gitlab-ci.yml文件中一样容易上手。非Ultimate级别上的客户可以通过下载SAST作业工件与生成的SAST漏洞报告进行交互。

指导的SAST配置经验（ULTIMATE）

GitLab的静态应用程序安全测试（SAST）现在支持新的引导式配置体验。现在，只需单击两次即可启用SAST。相信安全性是团队共同努力的结果，这种配置经验使非CI专家可以更轻松地开始使用GitLab SAST。该工具可帮助用户创建合并请求以启用SAST扫描，同时利用最佳配置实践。

GitLab SAST 涵盖14种分析仪中的18种语言，因此有许多SAST配置选项，可能很难理解和设置。这种新的指导性SAST配置体验可帮助任何人入门SAST，并为引入新的配置选项（例如自定义规则集等）奠定了基础。

DAST漏洞证据（ULTIMATE）

DAST扫描发现的漏洞可能很难重现，因为该漏洞可能仅在某些情况下才能重现。尝试修复该问题时，也可能很难确定导致该问题的代码。DAST扫描发现的漏洞证据现在已包含在漏洞详细信息中，从而使复制和修复更加容易。

容器网络策略控制（ULTIMATE）

容器网络策略控制提供了一种易于发现的方式，可找到有关如何为Kubernetes集群安装和卸载容器网络策略的文档。可以在操作> Kubernetes>应用程序页面的新 GitLab容器网络策略部分中访问这些控件以及当前容器网络策略状态的可视指示器。

切换Epic机密（PREMIUM及以上）

由于机密已准备好在更公开的级别上共享，因此可能很难共享一系列问题及其父级Epic。现在，可以切换Epic的机密性，为具有适当访问权限的人启用或禁用可见性。

有关项目安全仪表板的其他详细信息（ULTIMATE）

通过向漏洞列表添加新的数据字段，Project Security仪表板变得越来越有用。在主仪表板上放置更多详细信息可以更好地概述项目的漏洞，而不必打开各个漏洞页面。

对于针对源代码运行的扫描程序，现在可以在易受攻击的文件中看到行号。还包括扫描仪类型（SAST，DAST等）和供应商名称。还可以按类型和供应商进行过滤。即使已经集成了第三方扫描程序，也可以轻松快速地钻取特定漏洞的子集。

还改进了漏洞标识符的显示。对于给定漏洞，许多扫描程序可以包含多个标识符，例如CVE，CWE或专有ID。以前，选择了提供的第一个标识符以显示在漏洞列表中。现在，将始终显示CVE（如果有）,还包括其他标识符的总数。

将现有问题链接到漏洞（ULTIMATE）

通过使用户能够将现有问题链接到漏洞，gitlab正在增强漏洞管理工作流程。此前，只能通过从漏洞记录中创建新问题来将单个问题与漏洞相关联。这些问题是在与漏洞记录相同的项目中自动创建的。

使用此新功能，可以将一个或多个现有问题链接到漏洞。也可以链接其他项目的问题。在管理漏洞（尤其是跨项目）时，这为安全和开发团队提供了更大的灵活性和可见性。

性能改进

在每个版本中，gitlab继续在改善性能方面取得重大进展。致力于提高每个GitLab实例的速度。GitLab 13.3中的一些显著性能改进包括：

调查并减少Project::NotesController＃create的'CACHE'SQL数量；

banzai参考筛选器的卷展更新节点优化功能；

目范围内搜索中浪费的额外项目ID过滤；

通过强大的备忘功能解决面板列表问题服务中的N + 1问题。

Bug修复

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

通过API创建新版本时，不会保存版本资产链接类型和文件路径；

Gitlab页面的访问控制导致503错误；

无法取消创建新版本；

页面访问控制不会在身份验证中获取自定义CA证书；

移动链接的问题后，加载漏洞列表时出错；

镜像项目不会将标签复制到辅助节点；

使用相对网址的辅助网站无法登录；

GEO：无法通过快照重新下载存储库；

Jira问题引入项目选择限制为100个结果；

Markdown未在新的迭代或迭代报告中呈现；

迭代问题列表不包括子组问题；

搜索结果页面错误/任意更改了排序顺序；

生成的Blob ID太长，无法由Elasticsearch处理；

高效计数器；

API端点找不到子管道及其作业；

将问题添加到机密Epic中时，从建议中删除公开问题；

功能弃用Debian Jessie和Raspbian Stretch被弃用

弃用日期：2020年8月22日

Debian Jessie和Raspbian Stretch在2020年6月停止更新。GitLab13.3是这些发行版的最后一个受支持版本。

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

弃用日期：2021年1月22日

目前，GitLab支持针对应用程序日志的text/json/logstash日志格式和针对访问日志的text/json/combined。将弃用logstash和组合格式，仅使用两个选项（文本（用于开发）和json）统一应用程序和访问日志的格式化程序。

弃用Container Registry日志挂钩

弃用日期：2021年1月22日

Container Registry支持日志挂钩，目前仅可用于电子邮件通知。

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

为了简化注册表功能和配置，将放弃对日志记录挂钩的支持。

弃用Container Registry maxidle和maxactive Redis池设置

弃用日期：2021年1月22日

当前为Redis连接池公开的一些配置设置与基础Redis客户端绑定，并且在替代库中没有等效设置。在开始改进Redis集成（例如增加对Sentinel的支持）的过程中，决定开始着手以功能更丰富，支持更好的替代方法来替换当前的Redis客户端依赖项。为此，需要替换绑定到当前客户端库的当前Redis池配置设置。

计划删除redis.pool.maxidle和redis.pool.maxactive设置，并添加redis.pool.size（最大连接数），redis.pool.miniddle（最小空闲连接数）和redis.pool.maxlifetime（可以重用连接的最大时间）。

弃用Container Registry代理透传缓存

弃用日期：2021年1月22日

有些容器注册表功能已过时或不再使用（至少在GitLab上）。支持这些功能限制了清理代码库并减少第三方依赖项列表的能力。

本proxy部分允许将Container Registry设置为上游存储库的本地镜像。在用于GitLab部署的注册表环境中，这样做的用处不大，用户很可能会将其注册表部署与GitLab实例并置在一起，而不是使用托管在单独基础架构（例如Docker Hub）上的注册表服务。

弃用Bugsnag的Container Registry支持

弃用日期：2021年1月22日

Bugsnag是容器注册表支持的错误报告服务之一。据调查，没有一个用户依赖此服务，在GitLab使用Sentry。为了简化和合并受支持的错误报告服务，打算增加对Sentry的支持，并删除对Bugsnag的支持。

弃用对NewRelic的Container Registry支持

弃用日期：2021年1月22日

NewRelic是容器注册表支持的错误报告服务之一。据调查，没有一个用户依赖此服务，在GitLab使用Sentry。为了简化和整合支持的错误报告服务，打算添加对支持，并删除对NewRelic的支持。

在机密检测模板中弃用SAST_EXCLUDED_PATHS

弃用日期： 2020年8月22日

为了使托管CI模板保持一致和简化，SAST_EXCLUDED_PATHS将Secret Detection CI模板中的变量重命名为SECRET_DETECTION_EXCLUDED_PATHS。这将始终将所有Secret Detection CI模板变量命名为以开头SECRET_DETECTION_。请注意，这SAST_EXCLUDED_PATHS仍然是SAST CI模板中的有效变量。该更改仅影响秘密检测CI模板。作为过渡，如果使用一个定制的秘密检测CI模板，请更新的变量名模板。如果使用Auto DevOps或继承GitLab的托管安全模板，则无需执行任何操作。

不推荐使用GEO外部数据包装器设置

弃用日期：2021年4月17日

从GitLab 13.2开始，Geo不需要为数据复制配置外部数据包装器（FDW）。以下配置设置/etc/gitlab/gitlab.rb已弃用，将在14.0中删除：

geo_secondary['db_fdw']

geo_postgresql['fdw_external_user']

geo_postgresql['fdw_external_password']

gitlab-_rails['geo_migrated_local_files_clean_up_worker_cron']

WIP（进行中的）合并请求术语已弃用

弃用日期：2021年4月17日

将合并请求的WIP（在进行中）术语重命名为"草稿"，因为它更具包容性且不言自明。现在不建议使用WIP术语。将在下一个主要的GitLab版本（14.0）中支持它的使用，然后将其删除。

弃用日期：

GEO rake任务以刷新已删除的外部表

删除日期：2020年8月22日

从GitLab 13.2开始，Geo不需要为数据复制配置外部数据包装器（FDW）。geo:db:refresh_foreign_tables不再需要rake任务，并且在此版本中已将其删除。

删除SAST机密检测作业以使用新模板

删除日期：2020年9月22日

从GitLab 13.1开始，机密检测CI/CD配置设置在单独的GitLab提供的模板中提供，并作为新的安全扫描类型运行。现在，Auto DevOps中还包含了这个新的机密检测模板，以便于设置。

在13.4中，将删除旧的SAST secrets-sast作业定义，并且如果尚未切换到新的"机密检测"模板，则不会继续扫描秘密。可以通过添加新模板轻松地进行过渡。

在升级到GitLab 13.4之前，建议将新的Secret Detection模板添加到gitlab-ci.yml文件中，然后从文件中的SAST配置模板中删除旧的SAST secrets-sast作业定义。

升级更新Omnibus版本升级

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

yum updata/install gitlab-ce

就能自动完成升级：

docker安装实例

先停止和删除旧的容器：

sudo docker stop gitlabsudo 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 pulldocker-compose up -d