按照惯例GitLab发布有一个新的月度版本13.4.，本次发布主要带来了VaultforCI变量，KubernetesAgent和S安全中心能功能帮助团队降低风险，提高效率并加快交付速度，并提升到安全性，降低漏洞，提高效率，使用户体验更好，并帮助的团队更快地部署等。请追随虫虫一起来学习一下GitLab13.4带来的新的功能。
本月的发行版为GitLabDevSecOps套件增加了一些功能。首先，作为构建和部署过程的一部分，现在可以将存储在HashiCorpVault中的机密注入CI/CD作业中。
代码部署职责分开的组织可以通过Reporter访问Deployer角色来提升特定用户。部署者角色遵循最小特权访问的原则，允许他们批准合并请求并将代码部署到受保护的环境，而无需访问修改代码本身。
降低风险的另一种方法是使用新的GitLabKubernetes代理。运营商可以从GitLab部署到其Kubernetes群集，而无需将其群集打开到整个网络。GitLab托管Terraform状态的新Terraform状态文件引入自动版本控制支持，以支持合规性和调试需求。最后但并非最不重要的一点是，实例安全性仪表板已演变为具有漏洞报告和设置功能的GitLab安全中心。
通过从搜索栏进行快速导航来快速跳转到最近的问题，组，项目，设置和帮助主题，从而改进了全局搜索功能。对于GitLab页面重定向，能够重定向站点中的各个页面和目录，这使用户能够更高效地部署页面站点。
对于那些希望获得增强的部署信息的人，新版本使可以从环境仪表板管理数百个受支持的项目部署。
GitLab13.4主要功能改进
介绍GitLabKubernetes代理（PREMIUM及以上）
长期以来，GitLab的Kubernetes集成使无需手动设置即可部署到Kubernetes集群。许多用户都喜欢易用性，而其他用户则遇到了一些挑战。当前的集成要求集群对Internet开放，供GitLab访问。对于许多组织来说，这是不可能的，因为他们必须出于安全性，合规性或监管目的而锁定群集访问。
最新的GitLab版本中发布了GitLabKubernetes代理：一种部署到Kubernetes集群的新方法。
该代理在集群内部运行，无需将其打开到网络。代理通过从GitLab提取新更改来协调部署，而不是GitLab将更新推送到集群。无论使用哪种GitOps方法，GitLab都可以满足的要求。
注意，这这次发布是代理的第一个版本。当前，GitLabKubernetes代理具有配置驱动的设置，并可以通过代码进行部署管理。尽管不支持某些现有的Kubernetes集成功能，例如DeployBoards和GitLabManagedApps，将在未来迭代中最终实现这些功能，并与代理提供注重安全性和合规性的集成。
在GitLabStarter中提供了功能标记（STARTER及以上）
GitLab11.4中引入了功能标记。在12.2中，GitLab引入了百分比推广和用户ID功能标记策略。在13.1中，引入了功能标记用户列表，并支持每个环境多个功能标记策略。
今年早些时候，GitLab承诺将18个功能免费发布到CE产品中。在该版本的已经完成了将功能标志移动到Starter的工作，并且继续将功能标志服务迁移，在GitLab13.5中在Core免费发布。
使用搜索栏快速导航
在GitLab上浏览时，有时只想转到特定项目而不是搜索结果页面。
使用全局搜索栏，在新版本中可以快速跳转到最近的问题，组，项目，设置和帮助主题。甚至还可以使用/键盘快捷键将光标移至搜索栏，从而更有效地导航。
MR差异内部的内联代码覆盖率备注
在查看合并请求时，很难确定修改后的代码是否包含在单元测试中。审阅者可以改为依赖总体覆盖范围值，并要求在批准合并请求之前增加该值。这可能会导致开发人员采用分散的测试编写方法，但实际上可能无法提高代码质量或覆盖范围。
现在，开发人员在进行审阅时将在合并请求差异中看到代码覆盖率的可视化表示。该可视指示器可以轻松查看修改后的代码是否包含在单元测试中，从而有助于加快代码审阅以及合并和部署功能的时间。
使用环境仪表板大规模跟踪环境（PREMIUM及以上）
从GitLab12.5开始，使用环境面板只能在3个项目中看到7个环境。通过对仪表板进行分页来帮助大规模支持和管理环境，新改的GitLab13.4中的环境仪表板，可以在项目中看到更多环境。
GitLabTerraform维护权
最近已经获得了GitLabTerraform提供程序的维护者权利，并计划在即将发布的版本中对其进行增强。在过去的一个月中，GitLab合并了21个请求请求并关闭了31个问题，其中包括一些长期未解决的错误和缺少的功能（如支持实例集群）。可以在Terraform文档中阅读有关GitLabTerraform提供程序的更多信息。
使用OpenAPI规范或HAR文件进行API模糊测试（ULTIMATE）
API模糊测试是在Web应用程序和API中查找其他扫描程序和测试技术所缺少的错误和漏洞的好方法。
GitLab的API模糊测试可让提供OpenAPIv2规范或应用程序的HAR文件，然后自动生成旨在解决极端情况并查找错误的随机输入。然后，结果立即显示为管道的一部分。
这是API模糊测试的第一个版本，后续将会持续改。
在用户界面中预览新的指标图表
在GitLab指标仪表板中创建图表具有挑战性。在仪表板YAML文件中定义了图表之后，在master不知道新创建的图表就是想要的内容的情况下，会误提交更改了。
从GitLab13.3开始，可以在创建图表时预览面板的YAML，从而在将更改提交到仪表板的YAML文件之前获得早期反馈。
组中所有项目的代码覆盖率数据（PREMIUM及以上）
当的团队管理多个GitLab项目时，应该能够轻松地看到一个数据点，该数据点显示了所有项目中代码覆盖率随时间的变化趋势。以前，可视化此趋势涉及繁琐的手动操作，需要从每个项目中下载覆盖率数据并将其插入电子表格中。
现在，以团队负责人的身份，可以快速轻松地收集每个小组项目或选定项目中可用的所有代码覆盖率数据作为.csv文件。这是一项MVC功能，随后将可以绘制随时间变化的平均覆盖范围。
对语言覆盖测试的新语言支持（ULTIMATE）
此版本在覆盖率指导的模糊测试中引入了对多种新语言的支持。
现在，可以对以Java，Rust和Swift编写的应用程序进行模糊测试的所有功能，以发现其他进程遗漏的错误和安全漏洞！
在环境索引页面中显示告警（ULTIMATE）
环境页面显示了环境的一般状态。在此版本中，通过添加告警改进了环境页面。在环境状态旁边看到触发的告警，可以立即采取措施进行补救。
子管道现在可以触发自己的子管道
使用父/子管道时，子管道现在可以触发自己的子管道。当希望灵活地生成可变数量的子管道时，这种增加的深度可能很有用。
在使用父/子配置之前，每个子管道都需要在父中手动定义的触发作业。现在，可以生成动态触发任意数量的新子管道的子管道。例如，如果有monorepo，则可以根据分支中的更改动态生成第一个子管道，该子管道本身会生成可变数量的新子管道。
改进了父子管道之间的导航
在父管道和子管道之间进行导航比较麻烦，需要多次单击。区分哪个作业触发了哪个子管道也不容易。现在，可以更轻松快捷地查看父管道与子管道的连接方式。
并行矩阵作业在作业名称中显示相关变量
如果使用矩阵作业，可能会注意到很难确定每个作业使用的矩阵变量，因为作业名称的格式类似于matrix1/4。在13.4中，现在将看到在该作业中使用的相关变量值，而不是看到通用作业名称。例如，如果要构建x86体系结构的调试目标，则该作业现在将命名为matrix:debugx86。
连接Atlassian帐户
GitLab用户现在可以将其GitLab帐户连接到其AtlassianCloud帐户。连接帐户允许用户使用其Atlassian凭据登录GitLab。此更改也为将来增强GitlabJira集成以及与Atlassian套件中的其他产品集成奠定了基础。
Core中现已提供相关问题和更多内容
几个月前，GitLab宣布了开放18种功能的计划。为了兑现这一承诺，Core中现在提供了相关问题，问题CSV导出和问题委员会重点模式。这仅适用于关联关系。阻止和被阻止保留在付费层中。
在合并请求侧栏中显示源分支名称
在查看代码更改，讨论和合并请求中的提交时，通常需要在本地检出分支以进行更深入的查看。但是，随着更多滚动内容的出现，随着更多内容添加到合并请求描述中，查找分支名称变得更加困难。
现在已将分支名称添加到合并请求侧栏中，从而使其可以随时轻松访问，并且无需滚动。就像合并请求参考一样，源分支部分提供了一个方便的复制按钮，可以方便地进行本地检出。
在合并请求差异中强调折叠差异
将更改应用于多个文件的合并请求有时会折叠大文件差异，以提高性能。发生这种情况时，很容易忽略文件而不查看它，尤其是在合并具有多个文件的请求中。从GitLab13.4开始，合并请求将强调包含折叠文件的差异，这将确保在代码审阅过程中审阅者不会丢失这些文件。
在设计视图中将待办事项标记为完成
GitLab中的有效沟通取决于待办事项列表。如果在评论中被提及，那么能够遵循待办事项并采取行动或将其标记为已完成至关重要。当需要记住做某事或稍后再回来时，能够自己做事也很重要。
直到现在，都无法在设计上添加待办事项或将其标记为已完成，这令人非常沮丧。这确实削弱了产品团队之间的沟通效率，因为待办事项对于在GitLab中管理工作流程至关重要。
从13.4版开始，设计可以与问题注释保持一致，并且可以使用待办事项以获得更加一致和有用的体验！
文件折叠时对合并请求差异的警告
在合并请求diff上折叠大文件是为了增强合并请求中diff部分的性能和响应能力。但是，在代码检查期间，由于滚动了大文件，检查者在滚动文件列表时可能会丢失某些文件。
合并请求差异页面的顶部引入了可见警告，明确告知用户该部分中的文件已折叠。这样可以确保对合并请求中的所有相关更改进行审核。
改进的CI/CD故障排除指南
新改进了GitLabCICD故障排除指南，其中包含有关可能遇到的常见问题的其他信息。希望改进后的文档是宝贵的资源，可帮助使GitLabCI/CD轻松快速地启动并运行。
合并请求并非意外从合并中删除（PREMIUM及以上）
以前，合并请求可能会因后期评论而意外地从合并中删除。如果合并请求已经在合并火车上，并且有人添加了一个注释，该注释创建了一个新的未解决的线程，则该合并请求被认为是不可合并的，并从火车上删除了。现在，在将合并请求添加到之后，可以进行新注释，而无需担心破坏合并过程。
显示MR中代码覆盖率值的作业数据
作为开发人员，即使在复杂的情况下（例如，管道中有多个要解析的工作来计算覆盖率值的情况），也应该能够在管道完成运行后轻松查看代码覆盖率。到目前为止，合并请求窗口小部件仅显示这些值的平均值，这意味着必须导航到作业页面，然后返回到合并请求本身以获取有关覆盖范围值的更详细的详细信息。为了节省的时间并消除这些额外的步骤，现在向介绍平均覆盖率值，它与目标分支和源分支的关系以及工具提示，该提示显示用于计算平均值的每个作业的覆盖率。
查看组时删除程序包注册表程序包
GitLab软件包注册表是存储和共享各种软件包格式的地方。当项目或组中有大量软件包时，希望快速识别未使用的软件包并将其删除，以防止人们安装错误的软件包。可以使用PackagesAPI或PackageRegistry用户界面从注册表中删除软件包。但是，直到最近，仍无法在UI中查看组时删除软件包。
现在，可以在查看组的程序包注册表时删除程序包。只需导航到组的PackageRegistry，按软件包名称过滤，然后删除所有不需要的软件包。
将conan的范围扩展到项目
可以使用GitLabConan存储库发布和共享C/C++依赖项。但是，程序包以前只能限于实例。这是有问题的，因为Conan软件包名称必须少于或等于51个字符。对于任何试图发布位于小组之内的软件包的人，gitlab-org/ci-cd/package-stage/feature-testing/conan使用该功能几乎是不可能的。
现在，可以将Conan软件包的作用域限定为一个项目，从而可以轻松发布和共享项目的依赖项。
在合并请求中设置管道成功合并时时的通知
当审阅者将合并请求（MR）设置为管道成功合并（MWPS）时，不会发送电子邮件通知。MR合并后，必须手动检查以查看状态或等待通知。在此版本中，通过在审阅者将MR设置为MWPS时自动通知合并请求线程中的所有订阅者来解决此问题。
使用用户指定的Kubernetes版本创建EKS集群
GitLab用户现在可以选择要在EKS上配置的首选Kubernetes版本。与EKS上支持的Kubernetes版本保持一致，用户可以在1.14-1.17版本之间进行选择。
将事件创建为问题类型
并非所有出现的问题都会首先触发告警：客户报告故障，团队成员确定性能问题。现在，事件是一种问题，因此团队成员可以通过熟悉的工作流程快速创建事件。在GitLab中的任意位置单击新问题，然后在类型字段中选择事件。
Markdown中的参考GitLab告警
在GitLab风格的Markdown中添加了特定于告警的参考，从而改进了告警，使可以轻松共享和参考告警。用于^alert#在事件，问题或合并请求中的任何Markdown字段中引用告警。此告警参考还可以帮助确定告警产生的待办事项，而不是问题或合并请求。
查看事件的告警有效负载
告警的有效负载包含诊断故障和恢复服务的关键信息，并且该信息必须易于访问，因此在解决事件时无需切换工具或选项卡。通过告警创建的事件会在告警详细信息选项卡中显示告警的全部有效负载。
高级搜索中的搜索结果快75%（STARTER及以上）
在GitLab13.4中，当仅限于特定的名称空间和项目时，高级搜索现在将结果输出速度提高75%。
管理员的已删除项目视图
12.6中引入了延迟项目删除的功能。但是，以前没有办法将所有待删除的项目集中在一处。现在，自建实例的管理员可以在单个视图中查看所有待删除项目，以及可以轻松还原这些项目的按钮。
此功能使自建实例的管理员可以通过在单个位置汇总此信息并提供撤消不希望的删除活动的机会来更好地控制项目删除。
向API添加了组推送规则支持（STARTER及以上）
以前，只能通过GitLabUI分别访问每个组并应用这些规则来配置组推送规则。现在，可以通过API管理这些规则，以支持自定义的GitLab工具和自动化。
静态站点编辑器的配置文件
在GitLab13.4中，新引入了一种配置静态站点编辑器的新方法。尽管配置文件在此版本中不存储或检索任何值，但为自定义编辑器行为奠定了基础。
在即将发布的版本中，将为添加值，.gitlab/static-site-editor.yml以设置网站的基本URL，从编辑器上传的图像的存储位置，覆盖Markdown语法首选项和其他特定于编辑器的设置。
静态站点编辑器编辑
前端问题是一种灵活方便的方法，可以在旨在由静态站点生成器解析的数据文件中定义特定于页面的变量。它通常用于设置页面的标题，布局模板或作者，但是当页面呈现为HTML时可以用于将任何类型的元数据传递给生成器。每个数据文件的最顶部都包含前端内容，通常将其格式化为YAML或JSON，并且需要一致且准确的语法。不熟悉特定语法规则的协作者可能会无意中引入无效的标记，从而可能导致格式问题甚至构建失败。
静态站点编辑器的WYSIWYG编辑模式已经从编辑器中删除了前端内容，以防止出现这些格式错误。
在GitLab13.4中，可以在一个熟悉的基于表单的界面中访问和编辑每个前沿问题字段的值。单击设置按钮将显示一个面板，该面板显示定义的每个键的表单字段。使用当前值填充字段，编辑其中的任何一个就像在Web表单中键入一样简单。以这种方式编辑主题，可以避免语法复杂性，并可以完全控制内容，同时确保最终输出的格式一致。
适用于Jira的GitLab和DVCS连接器现已加入Core
对于JiraGitLab的用户，GitLabforJira应用程序和DVCSConnector允许显示有关GitLab提交的信息并直接在Jira中合并请求。结合与Jira的本地集成，可以在工作时轻松地在两个应用程序之间来回移动。
在WebIDE中支持自定义JSON模式验证（PREMIUM及以上）
依靠人们以JSON或YAML格式编写配置的项目可能会引起问题，因为很容易打错字并弄乱事情。可以编写在CI管道中捕获此验证工具，但是使用JSON模式文件有助于提供文档和提示。
项目贡献者可以.gitlab/.gitlab-webide.yml在其存储库中的文件中定义自定义架构路径，该路径指定要验证的文件的架构和路径。在WebIDE中加载定义的文件时，将显示其他反馈和验证，以帮助创建文件。
有向无环图（DAG）关系限制增加到50
如果使用的是有向非循环图（DAG）管道，则可能会发现一个作业可以列出的10个作业的限制needs:是不够的。在13.4中，默认限制从10增加到50，以允许管道中的作业之间的关系网络更加复杂。
通过跳过作业改善了需求的行为
在某些情况下，对于needs依赖项，管道中跳过的作业有可能被认为是成功的，这允许以后的作业本来可以运行。此问题已在13.4中修复，并且可以正确处理跳过的作业的行为needs。
锁定最新的作业工件以防止删除
GitLab现在将自动在任何活动分支，MR或标签上锁定成功作业和管道的最新工件，以防止其根据过期时间被删除。这使设置更激进的到期策略来清除较旧的工件变得更容易，有助于减少磁盘空间消耗，并确保始终从管道中获得最新工件的副本。
CI/CD的管道效率指南
优化的CI/CD管道运行可以提高速度并节省成本。通过简短指南来改进文档，以使充分利用优化管道的优势。
测试报告按测试状态排序
单元测试报告是看到从管道的所有测试结果的简单方法。但是，如果有大量测试，则查找失败的测试可能很耗时。导致报表难以使用的其他问题包括难以滚动长的跟踪输出，并且对于少于1秒的测试，数据通常四舍五入为0。现在，默认情况下，测试报告首先将失败的测试排在报告的顶部，然后再按持续时间排序。这使查找故障和长时间运行的测试变得更加容易。而且，测试的持续时间现在以毫秒或秒为单位显示，因此读取速度更快，并且以前的滚动问题也已解决。
文件大小上传到PackageRegistry的限制
现在存在一些限制，这些限制限制了可以上传到GitLab软件包注册表的软件包文件的大小。添加限制是为了防止滥用并优化PackageRegistry的性能。限制因包装格式而异。对于GitLab在线仓，最大文件大小为：
·Canon：MB
·Maven：3GB
·NPM：MB
·NuGet：MB
·PyPI：3GB
对于自建实例，默认设置相同。但是，管理员可以使用Rails控制台更新限制。
使用CI_JOB_TOKEN发布PyPI软件包
可以在源代码和CI/CD管道旁边使用GitLabPyPI存储库来构建，发布和共享python软件包。但是，以前无法通过使用预定义的环境变量来对存储库进行身份验证CI_JOB_TOKEN。结果，被迫使用个人凭据来更新PyPI存储库，或者可能决定完全不使用存储库。
现在，使用GitLabCI/CD通过预定义的CI_JOB_TOKEN环境变量来发布和安装PyPI软件包比以往更加容易。
GitLab页面的简单重定向配置文件
对于GitLabPages的用户，希望更好地管理URL更改，则会遇到无法在GitLabPages站点中管理重定向的痛苦。现在，GitLab允许通过将配置文件添加到存储库来配置规则，以将Pages站点的一个URL转发到另一个URL。
GitLab托管Terraform
对于合规性和偶尔的调试需求，必须具有访问Terraform状态的先前版本的权限。从GitLab13.4开始提供对GitLab受管Terraform状态的版本控制。新的Terraform状态文件的版本控制会自动打开。现有的GitLab托管Terraform状态文件将在以后的版本中自动迁移到版本存储。
突出显示事件的关键告警详细信息
在对事件进行分类时，应该很容易确定告警已打开多长时间以及事件已触发了多少次。这些细节通常在确定客户影响以及团队现在需要做出响应时至关重要。在新的事件突出显示栏中，显示了告警的开始时间，事件计数，以及指向原始告警前端和中心的链接。此信息可用于告警引发的事件。
设置和编辑事件严重性
事件的严重性告诉响应者和利益相关者中断的影响以及响应所需的方法和紧迫性。当团队在故障处理过程中共享发现并补救中断时，可以编辑事件的严重性。现在，可以在事件详细信息页面的右侧边栏中编辑事件的严重性，严重性将显示在事件列表中。
创建，编辑和删除容器网络策略（ULTIMATE）
容器网络策略编辑器的这一改进使用户可以直接在GitLabUI中轻松创建，编辑和删除其策略。该编辑器的功能包括.yaml为经验丰富的用户提供的模式和为不熟悉网络策略的用户提供的直观规则编辑器UI。可以在安全性和合规性威胁管理策略中找到新的策略管理功能。
AzureBlob存储支持
GitLab和GitLabRunner现在都支持AzureBlob存储，这使得在Azure上运行GitLab服务变得更加容易。
GitLab实例支持所有对象存储类型的Azure，包括：LFS文件，CI工件，备份等。若要配置AzureBlob存储，请按照Omnibus或HelmChart安装的说明进行操作。
GitLabRunners还支持Azure来存储分布式缓存。可以使用该[runners.cache.azure]部分配置Azure存储。
适用于Ubuntu和OpenSUSE的OmnibusARM64软件包（ULTIMATE）
为了响应对在64位ARM架构上运行GitLab的支持的需求不断增长，很高兴地宣布正式提供ARM64Ubuntu20.04Omnibus软件包。要下载并安装Ubuntu20.04软件包，转安装页面并选择Ubuntu。
安全和合规性审计
安全中心（ULTIMATE）
如今，实例级别的漏洞管理经验在功能和灵活性上都受到限制。当前的经验是一个页面，其中结合了漏洞详细信息，指标可视化和配置。没有足够的空间来扩展这些功能或利用其他安全功能。
对GitLab中的安全可见性和管理进行了根本性的更改。实例安全仪表板已转换为安全中心。最大的变化是引入了新的菜单结构。现在，可以找到一个安全仪表板，漏洞报告和设置区域，而不是单个页面。尽管功能没有改变，但将其分解可以实现将来的增强，否则这些增强将是困难的。这还将创建一个顶层框架，以在将来包含其他与安全性相关的功能。
专用的漏洞报告现在具有更多空间来显示重要详细信息，并继承了当前在项目漏洞列表中找到的详细信息。将漏洞度量小部件分隔到各自的区域中可以创建一个真正的安全仪表板。现在，它是用于将来的可视化的专用画布，不仅用于管理漏洞，而且还用于与安全相关的任何指标。最后，将设置拆分为自己的区域可为漏洞管理之外的实例级安全配置创建新的共享空间。
导出所有合并提交的列表（ULTIMATE）
注重合规性的组织需要一种方法来向审核员展示与生产中任何特定更改有关的组件的整体视图。在GitLab中，这意味着连接所有点：MR，问题，管道，安全扫描以及其他有关提交的数据。到现在为止，必须挖掘GitLab应用程序和/或构建自定义工具来汇总信息-这不是很有效。
现在，可以以编程方式收集和导出此数据以满足审核要求，或者通过导航到合规性仪表板并单击按钮以导出该组的所有合并提交的列表来执行其他分析。生成的文件将包含所有合并提交及其作者，相关的合并请求ID，组，项目，批准者等。
通过API列出和撤消个人访问令牌（ULTIMATE）
管理对GitLab名称空间的访问是合规性计划的重要组成部分。从最小特权的原则到及时终止访问，GitLab中有一些与个人访问令牌相关的合规性要求。为了在命名空间中支持对这些用户凭据的更轻松，更好，更批量的管理，新引入了列出所有用户PAT并可以选择通过API撤消它们的功能。
对GitLabAPI功能的这些改进使用户可以列出和撤消其自己的PAT，并使管理员可以列出和撤消其用户的PAT。管理员现在可以更好地了解谁有权访问其名称空间，可以对用户的凭据做出数据明智的决定，并有权撤销可能已遭到破坏或可能超出公司的证书轮换政策的PAT。
授予用户部署权限，而无需访问代码（PREMIUM及以上）
如果团队需要在拥有开发的团队成员和拥有部署的团队成员之间保持职责分离，则GitLab中的权限范式使这一挑战变得棘手。
在GitLab13.4中，可以授予非代码贡献者权限以批准合并请求进行部署，并实际部署代码，而无需授予他们维护者访问权限。
在CI作业中使用HashiCorpVault机密（PREMIUM及以上）
在GitLab12.10中，GitLab引入了GitLabRunner的功能，以获取机密并将其注入CI作业。GitLab现在通过在文件中构建新语法来扩展JWTVault身份验证方法。这使可以更轻松地在GitLab上配置和使用HashiCorpVault。
扩展依赖项扫描支持的程序包管理器和语言
将使用NuGet4.9+或Conan软件包管理器的C，C++，C＃和.Net项目的依赖项扫描添加到GitLab支持的语言和框架中。作为安全阶段的一部分，可以启用依赖项扫描来检查程序包管理器中包含的依赖项是否存在已知漏洞。这些漏洞及其严重性级别将显示在合并请求中，因此可以在合并前了解新依赖项可能带来的风险。还可以将项目配置为对严重性为严重，高或未知的任何漏洞要求合并请求批准。
撤销用于自我管理的凭证库存的PAT
证书库存提供了洞察管理员需要管理用户访问凭据GitLab实例。随着注重合规性的组织在凭据管理策略的严格性方面的差异，新添加了一个按钮，管理员可以选择撤消用户的个人访问令牌（PAT）。管理员现在可以轻松撤消可能已遭到破坏的PAT。此功能为需要更灵活的实施选项的组织提供支持，以最大程度地减少对用户的干扰。
按需DAST扫描仪配置文件（ULTIMATE）
除了最新发行版中引入的DAST按需扫描外，DAST扫描器配置文件还允许快速创建多个配置文件，以涵盖多种扫描类型，从而扩展了这些扫描的配置选项。在13.4中，扫描程序配置文件最初包括蜘蛛超时选项，该选项设置DAST蜘蛛在尝试发现要扫描站点的所有页面时应运行多长时间。它还包含一个目标超时选项，用于设置扫描器在站点未响应或状态码的情况下，应等待多长时间才能中止扫描。在后续版本中继续迭代此功能，更多配置选项将添加到扫描仪配置文件中。
GitlabGeo高可用集群更新
GitalyCluster自动存储库修复
当主要的GitalyCluster节点脱机时，该节点上的存储库被标记为只读，以防止在未复制的更改发生时丢失数据。如果节点重新联机，则GitLab不会自动恢复，管理员必须手动触发，否则，必须接受数据丢失。其他情况也可能导致存储库过时或只读，例如无法在辅助节点上处理复制作业。在这种情况下，存储库将保持过期，直到再次进行写入并触发复制作业为止。
为了解决这些情况，Praefect现在计划在一个节点上检测到过时的存储库但在另一节点上检测到存储库的最新版本时安排复制作业。此复制作业会自动将过期的存储库更新为最新状态，从而减轻了对手动数据恢复的担忧。自动修复还可以确保在复制作业失败时快速将辅助节点恢复到最新状态，而不必等待下一次写入发生。由于许多Gitaly群集存储大量存储库，因此这大大减少了管理员和站点可靠性工程师在故障转移后需要花费时间来恢复数据的时间。
此外，自动修复启动将存储库复制到添加到群集的任何新Gitaly节点的功能，从而在添加新节点时无需手动干预。
GitalyCluster多数表决支持（测试版）
GitalyCluster允许在多个热Gitaly节点上复制Git存储库。通过消除单点故障来提高容错能力。在GitLab13.3中引入的参考事务导致更改被广播到集群中的所有Gitaly节点，但是只有与主节点一致投票的Gitaly节点才会将更改保存到磁盘。如果所有副本节点都不同意，则仅将一个更改副本保留到磁盘上，从而造成单点故障，直到异步复制完成。
多数表决支持通过要求多数节点在保留对磁盘的更改之前达成一致来提高容错能力。启用功能标志后，写入必须在多个节点上成功进行。异议节点通过异步复制自动地从形成仲裁的节点开始同步。
GitLabHelmchart改进
现已提供证书映像的RedHat通用基本映像（UBI）版本。以前，使用基于UBI映像的部署需要对证书容器使用非UBI映像。要使用此新映像部署GitLab，请global.certificates.image.tag=master-ubi8在values.yaml文件中指定。
Helm安装现在支持智能卡身份验证。
子图表已添加，用于部署和配置Praefect服务。Praefect允许跨Gitaly节点集群管理Git存储库的存储，以实现容错配置。
下载到Workhorse的存档文件的缓存已针对Helm图表安装被禁用。从Omnibus安装方法开始将存档缓存存储在本地磁盘上。在Kubernetes部署中，磁盘不会在Pod之间共享。存档会随着时间的推移而累积，因为无法清理存档文件。这可能会导致节点上磁盘使用率过多的问题。
现在可以在图表中启用内容安全策略（CSP），以帮助防止JavaScript跨站点脚本（XSS）攻击。
对GitLabHelm图表的智能卡身份验证支持（ULTIMATE）
现在，可以使用诸如通用访问卡（CAC）之类的智能卡对通过Helm图表部署的GitLab实例进行身份验证。使用X.证书针对本地数据库对智能卡进行身份验证。这使Helm图表与Omnibus部署中可用的智能卡支持相当。
Omnibus的改进
现在支持在ARM64上部署GitLab。
此发行版包括PostgreSQL的次要版本更新，从11.7到11.9，以及从12.3到12.4。
GitLab13.4包括Mattermost5.26。此版本包括通过实验性的侧边栏增强功能对频道进行分类和重新排序的功能，通过询问社区链接从Mattermost社区获得帮助的功能，以及更多功能。它还包括安全更新。建议从早期版本升级。
GitlabRunner13.4
还将发布GitLabRunner13.4。GitLabRunner与GitLabCI/CD协同工作，GitLabCI/CD是GitLab附带的开源持续集成服务。新功能包括：
将存储在HashicorpVault服务器中的机密用于CI/CD作业变量；
将AzureBlob存储用于运行程序缓存；
添加userns_mode对GitlabCI服务的支持；
允许覆盖Kubernetes执行者的Service容器资源；
允许覆盖Kubernetes执行器的Helper容器资源；
添加Kubernetes节点关联性设置。
Bug修复：
修复：使用PowerShell时，文件类型变量具有字节顺序标记；
修复：Docker身份验证随机行为；
修复：DockerWindowsGit克隆；
所有更改的列表都在GitLabRunnerCHANGELOG中。
性能改进
在每个版本中，GitLab将继续在改善性能方面取得重大进展。致力于提高每个GitLab实例的速度。
在GitLab13.4中，在问题，项目，里程碑等方面提高性能。GitLab13.4的一些改进包括：
修复具有N^2个查询的软件包版本渲染结果；
在某些情况下，将设置通知的加载时间从60s减少到2s；
具有较大描述的合并请求不再超时；
改善Snowplow遥测性能；
修复一些N+1GraphQL查询；
地理位置：提高打包文件查询的性能。
功能变化
DebianJessie和RaspbianStretch不再受支持
变更日期：年9月22日
DebianJessie和RaspbianStretch在年6月结束支持，GitLab13.4不提供支持。GitLab13.3是这些发行版的最后一个受支持的版本。请访问不推荐使用的操作系统页面以获取更多信息。
删除容器注册表日志格式化程序
变更日期：年1月22日
当前，GitLab支持针对应用程序日志的text/json/logstash日志格式和针对访问日志的text/json/