按照惯例，日前Gitlab官方发布了一个新的月度版本13.6。在GitLab 13.6中带了EC2自动部署，项目可见性改善，VSCode集成插件等，包括60多项新功能和改进，更多功能请和虫虫一起学习。

概述

改进的易用性和自动化以提高效率

为了方便用户使用Amazon Web Services（AWS） GitLab CI/CD，Auto DevOps现在已扩展为支持AWS，新版本可以无需Kubernetes（例如Auto DevOps之前需要的）就可以使用Auto DevOps。

Docker Hub已对docker pull请求实施速率限制。新版本减轻了对SaaS和自建实例用户的影响，并提供了在环境中使用Prometheus监视限制的共享方法。所有用户使用其CI/CD管道和Kubernetes集群保持安全。正在将”移至Core功能，对所有用户免费。

通过听取社区的反馈以使用更具描述性的默认分支，组所有者现在可以更加灵活地为新存储库（而不是分支）配置自定义默认初始分支名称 master。静态站点编辑器可以在项目中使用默认合并请求模板，从而减少了在提交更新描述后导航到合并请求的需要。

改善可见性，以便更快地制定决策

在Gitlab 13.6中，对多个仪表板和报告进行了改进，以帮助用户更快地制定决策。

通过合并请求和”完整代码质量报告”中包含的代码质量严重性，现在可以快速确定哪些代码质量违规对于合并前的解决至关重要。

对Project Security仪表板进行了更新，以包括最新运行管道安全扫描的结果，以及动态漏洞趋势图，以帮助掌握实时和历史漏洞趋势。还在合并请求中添加了模糊测试结果以及其他安全结果，并通过添加源文件名和行号来帮助用户快速找到确切的崩溃位置并进行修复，从而提高了此报告的可读性。

GitLab自建实例管理员可以查看其组织在过去12个月中流行功能（例如用户，项目，组，问题和管道）的使用趋势。

改进可扩展性以实现无缝的工作流程

Gitlab的目标是与在环境中使用的其他流行工具很好地配合使用，即使仅使用GitLab的一部分，也可以获得无缝的体验。在13.6中，为了使VS Code内的访问和协作变得容易，改进了VS Code的扩展，可以直接从VS Code插入片段，查看合并请求和问题并对其进行评论，而无需切换到GitLab界面。

除实例和项目级别外，现在还可以在组级别配置GitLab集成-帮助组所有者轻松管理集成。

GitLab 13.6中主要功能改进

自动部署到EC2

Auto DevOps已扩展为支持到Amazon Web Services的部署。现在，即使没有Kubernetes，也可以部署到AWS Cloud Compute（EC2）利用Auto DevOps。为了实现这个工作流程，必须启用自动的DevOps并定义AWS类型的环境变量AWS_ACCESS_KEY_ID，AWS_SECRET_ACCESS_KEY和AWS_DEFAULT_REGION。这使可以利用AWS CloudFormation API来配置自己的基础架构。然后，可以将先前构建的工件推送到AWS S3存储桶，并将内容部署到AWS EC2实例。EC2部署会自动建立一个完整的自动交付管道，而无需额外的手动步骤。

Postman对API模糊测试的支持（ULTIMATE）

新版中可以使用 进行API模糊测试！Postman集合是已经在测试过程中创建的API的预定义描述。如果尚未创建它们，则很简单。

这是对已有资源使用模糊测试的好方法。要将Postman集合用于模糊测试，请将Postman集合添加到的仓库中，并在.gitlab-ci.yml文件中指出其位置 。然后，模糊引擎引用它进行模糊测试。

使用Postman集合进行的API模糊测试与使用OpenAPI规范或HAR记录进行的模糊测试运行所有相同的检查。

显示代码质量严重性等级

GitLab中的代码质量功能可以很好地显示项目中存在的质量冲突或合并请求中正在更改的质量。但是，目前在GitLab界面中尚不清楚了解哪些违规最重要。

使用”完整代码质量报告”和”合并请求”小组件，现在可以看到严重等级。这样很容易理解在合并之前解决哪些代码质量违规最重要，并减少了项目中的技术负担。

显示选定项目的代码覆盖率数据（PREMIUM及以上）

在13.4版中，发布了针对组的代码覆盖率数据的第一版，可以比较多个项目的覆盖率，并从单个屏幕将数据下载到单个文件中。但是，要分析数据，必须打开文件以手动检查它，并可能将其导入电子表格中以进行进一步分析。在GitLab 13.6中，可以选择组中的特定项目以直接在GitLab本身中查看其最新coverage值，而无需下载文件或浪费开发时间来访问代码coverage数据。

在GitLab中定义测试用例（ULTIMATE）

迈向项目级质量管理的第一步。该初始版本允许用户从GitLab内定义和查看测试用例。

将所有质量管理工具都保存在单个DevOps系统中对于确保单个真相来源和所有参与者协作和理解上下文的唯一位置至关重要。能够在GitLab中定义测试用例是该愿景的第一步。此后，打算通过创建测试会话，整体质量管理仪表板以及查看跨多个部署目标（例如阶段和生产）的测试历史记录的能力来建立此基础。

项目集成的组级管理

在GitLab 13.3中，添加了启用跨整个实例集成的功能。在GitLab 13.6中，该功能得到了扩展，以允许在组级别管理集成。

现在，组所有者可以将集成添加到组中，并且该集成将被该组下的所有项目继承。这有可能节省大量时间，因为许多组织都希望将特定的集成推广到他们创建的每个项目中。

一个很好的例子就是使用Jira集成。如果使用的是Jira，那么几乎整个公司都在使用它。这些公司中有一些拥有数千个项目，因此必须分别配置每个集成。

通过项目集成的组级管理，可以在每个上级组中添加集成，从而将所需的配置量减少了几个数量级！

里程碑燃尽图和历史上准确的报告（STARTER及以上）

里程碑或迭代燃尽图可以帮助跟踪整个范围的完成进度，但不能提供有关范围在时间范围内如何变化的见解。对于里程碑或迭代的初始承诺范围实际完成了多少，它先前也没有保留历史准确性。

为了解决这些问题并帮助团队更好地了解范围蠕变，里程碑和迭代现在显示了一个燃尽图，该图可以跟踪在给定时间内添加到并完成的问题的每日总计数和权重。

重构了燃尽图，以使用不可变的资源状态事件，以确保里程碑和迭代图在历史上仍然准确，即使在将问题移至另一个时间盒之后也是如此。

仅适用于在GitLab 13.6或更高版本中创建的里程碑和迭代。在13.6之前创建的里程碑仍然可以访问旧版燃尽图。

通过API更改Canary权重（PREMIUM及以上）

增加对金丝雀重量入口注释的支持是在GitLab中实现负载平衡器的第一个迭代。目的是提供一种配置NGINX批注的简便方法，以便可以自定义它们的行为。简而言之，这在配置高级部署时为提供了更多的灵活性。以前，仅在.gitlab-ci.yml文件中支持更改金丝雀重量。现在，可以更好地控制高级部署，并可以引入基于触发器的部署。

在功能标志更改时触发Webhook

作为开发人员，可以将GitLab的webhook功能用于各种事件，例如MR事件，管道事件，作业事件和部署事件。在此版本中，当功能标记被打开或关闭时，现在可以使用webhook事件。此添加简化了更新CI/CD管道，接收事件的Slack通知等过程。

在UI中按名称对发布进行排序

如果有数百个带有发行说明的发行标签，那么发行页面可能既令人困惑又难以浏览。随着新排序组件的实施，可以按日期和名称快速对发布进行排序，以更有效地查找相关信息。

默认情况下，新用户注册需要管理员批准

在GitLab 13.5中，引入了要求管理员批准新用户注册的选项。为了提高默认配置的安全性，GitLab 13.6将此选项设置为新实例的默认体验。当新的注册发生时，还向实例管理员引入了电子邮件通知，而在他们的注册被批准时也向用户引入了电子邮件通知。在此过程中这些关键步骤的电子邮件通知有助于减少需要管理员批准时向机载用户的周转时间。

MR分析的日期过滤和改进的数据表（STARTER及以上）

在GitLab 13.3中，引入了合并请求分析，它可以帮助用户更有效地评估合并请求吞吐量的效率和生产力。GitLab 13.6引入了对合并请求分析的进一步增强，现在可以按日期范围，批准元数据和数据表的分页进行过滤。

可视化用户，项目，组，问题，MR和管道活动

管理员通常需要有关如何使用GitLab的”概览”。实例统计信息功能可帮助管理员快速了解整个实例中关键功能的使用趋势。管理员现在可以查看图表，这些图表描述了过去12个月中的流行功能，例如用户，项目，组，问题和管道。

在其第一次迭代中，Instance Statistics需要管理员权限，这意味着它仅在GitLab的自托管安装中可用。在将来的迭代中，其他用户可以选择限制访问权限，从而更方便地访问此数据。请注意，为了支持此路线图，实例统计信息将在13.7中重命名为使用趋势，以使此功能更广泛地可用。

面板Epic泳道显示（PREMIUM及以上）

通常，在查看发行版时，可能难以识别与特定工作流相关的工作。为了提供更高的清晰度并帮助跨团队组织工作，Gitlab发布了第一个发行板泳道选项Epic，快速将工作分组在问题板各列的水平通道中，使用户可以轻松查看与Epic相关的所有工作以及它的状态。

使用按钮将问题升级为Epic（PREMIUM及以上）

将问题提升为史诗级功能，以前是依靠问题描述或评论中的/promote快速操作，这给常见且重要的操作增加了一些摩擦。为了使此操作更易于发现，新版本中在问题标题中引入了新的辅助操作菜单，并添加了一个按钮，可通过单击快速将问题升级为Epic。

自定义组中新项目的初始分支名称

创建新的Git存储库时，master默认情况下会命名第一个创建的分支。在与Git项目，更广泛的社区以及其他Git供应商的协调下，GitLab一直在听取开发社区对确定默认分支的更具描述性和包容性名称的反馈，现在为用户提供了更改默认名称的选项。其存储库的分支名称。

此前，提供了在实例级别自定义初始分支名称的功能，并且作为13.6的一部分，GitLab现在允许组管理员为通过GitLab界面创建的新存储库配置默认分支名称。

改进的设计管理通知

到现在为止，关于设计的通知与其他GitLab通知完全不一致，因为除非被@提及，否则不会收到电子邮件。这样跟踪设计讨论有点麻烦。

在13.6中，添加了一致的通知，因此，如果以某种方式参与了设计（留下评论，回复或@提及），将能自动收到每封新评论的电子邮件。

直接在VS Code中插入GitLab代码片段

项目概述是在团队之间共享代码片段的地方。这些代码片段通常包含可在多个地方重复使用的代码片段，或有助于引导相似的页面和组件。

在为项目做贡献时，找到这些代码片段并将其内容插入到工作文件中可能很重要。找到这些内容需要从编辑器中切换上下文，然后复制/粘贴正确的信息。

现在，使用VS Code扩展GitLab Workflow v3.5.0，可以将片段插入到工作文件中，同时支持单文件片段和多文件片段。

静态站点编辑器更改的合并请求模板

对于使用静态网站生成器创建的网站，可以使用”静态网站编辑器”以熟悉且直观的界面快速编辑页面内容。编辑完成后，甚至可以直接从编辑器创建合并请求。在GitLab 13.5中，新添加了设置合并请求标题和描述的功能，但是合并请求描述模板不可用。这意味着从静态站点编辑器创建的合并请求将具有不一致的描述，并且会丢失模板（如清单）中的任何有用信息。

在GitLab 13.6中，从静态站点编辑器创建的合并请求将使用默认的合并请求描述模板（如果已配置）。此外，可以从中选择并应用中定义的任何其他描述模板.gitlab/merge_request_templates，以确保为审阅者提供一致的消息传递，并减少了提交后必须导航到合并请求页面以更新描述的可能性。

在静态网站编辑器中上传图像

GitLab 13.1增加了对在静态站点编辑器中链接和预览图像的支持，只要图像已经托管在网络上某个位置，就可以直接支持。但是，仍然需要使用其他方法将新图像添加到站点，以将资产上载到项目存储库。

在GitLab 13.6中，不仅可以链接到图像，还可以从静态站点编辑器直接将图像上传到项目中，并在编辑时立即预览它。单击格式栏中的”添加图像”图标，将显示新选项，可以从计算机中选择文件。上载后，将以编辑器的WYSIWYG模式显示图像，并且在提交更改后，文件本身将包含在合并请求中。

分支和标签列表中的管道状态

如果将CI/CD管道与标签或分支一起使用，并且想知道最新的管道状态，则以前必须离开分支列表或标签列表才能进入管道页面。现在，将在其各自的列表视图中为每个分支或标签显示管道状态图标，因此只需单击几下即可快速获得许多标签或分支的此信息。

规则中的支持变量：change

gitlab-ci.yml脚本时间越长，它们维护和扩展就越困难。通过在rules: changes关键字中添加对环境变量的支持，现在可以将变量用于路径或文件名，而不会使CI文件过于冗长。变量可帮助在运行相同的CI作业以测试不同文件集中的更改时减少配置文件的总长度。

依赖代理开源

Docker Hub最近开始对来自Docker Hub的请求请求实施速率限制。现在，拉取速率受到限制，具体取决于为匿名用户使用的个人IP地址或通过身份验证并登录的定价层。

依赖代理可以通过缓存先前通过代理拉出的映像来帮助减少从Docker Hub发出的拉取请求的数量。因此，正在将该功能移至Core，以帮助解决这些新限制。通过在Core中支持代理和缓存，现在可以享受管道的更高可靠性和性能。

覆盖率指导的模糊测试结果现已可人工读取（ULTIMATE）

在模糊测试发现崩溃之后，下一步是对其进行调试，并找出崩溃发生的位置。仅使用十六进制地址可能很难做到这一点。现在为所有受支持的语言提供人类可读的，覆盖率指导的模糊测试结果。

这意味着当查看崩溃的堆栈跟踪时，可以看到随附的文件名和行号。这使用户轻松地转到发生崩溃的位置并进行修复。

将发布与组里程碑关联（PREMIUM及以上）

在GitLab 13.0中，可以通过Gitlab UI中的选择器将版本与里程碑关联。但是，利用组里程碑的用户无法将版本与该里程碑关联。现在，可以轻松地将组里程碑计划与发行版联系起来。

功能标记策略中的可搜索用户列表

之前添加了对用户列表的支持，作为功能标记策略。如果定义了许多用户列表，则很难找到要应用于特定策略的列表。为了使用户列表更易于查找和使用，新增加了从策略内搜索用户列表的功能。

跟踪已移至核心，对用户免费

为了在核心产品中提供可观察性的三个支柱，已经完成了最后一部分，并将跟踪类别移至了GitLab Core，对CE用户免费开放。

部署开始时添加聊天通知

先前的GitLab版本增加了对成功，取消和失败的部署的通知支持。在新版本中，还可以在部署开始时收到聊天通知。这样可以更好地跟踪部署状态，而不会影响正常的工作流程。

创建作业以停止ECS审核应用

最近添加了对AWS ECS的支持，因此可以将其用作Auto DevOps的部署目标。但是，针对ECS目标的审阅应用并没有自动停止。为了解决这个问题，Deploy_ECS模板已扩展为自动停止审阅应用程序，这是Auto DevOps流程的一部分，因此不会浪费资源。这样可以确保部署到ECS的Auto DevOps用户和使用Kubernetes的用户都具有类似的体验，无需手动停止并跟踪审阅应用程序即可自动运行。

在创建环境时设置自动停止环境有效期限

在此版本中，现在可以选择在创建环境时为审阅应用程序创建到期时间。过期时间是根据部署日期预先设置的，但是某些环境从未部署过。无论部署状态如何，此新功能都可以根据创建日期自动停止环境。

警告用户重试过时的作业

如果重试失败的部署作业，则环境可能会被旧的源代码覆盖。为防止意外发生，新版本中添加了一条消息，警告重试过时的作业。

在自定义仪表板上创建警报

警报对于使开发人员和运营商意识到其服务的运行状况和性能中断至关重要。以前，只能在GitLab的现成仪表板中为指标创建警报。从此版本的GitLab开始，可以在团队创建的任何自定义仪表板中的任何指标上配置警报。

Elasticsearch索引的高级搜索背景迁移（STARTER及以上）

向高级搜索添加功能通常意味着添加或更改内容编制索引的方式，并且这种索引更改将在几天内逐步发生。在过去的几个版本中，已经向”高级搜索”添加了许多功能，这意味着GitLab管理员必须在每次升级后手动执行重新索引。

从GitLab 13.6起，添加新的”高级搜索”功能时，无需手动干预即可在后台进行重新索引。在需要时仍可以手动执行重新索引。

GitLab Web界面现在可以通过自动调整图像大小来加速

GitLab显示许多用户提供的图像，例如问题和评论中的用户头像和图像附件。在GitLab 13.6之前，无论页面上如何使用图像，此内容都将未经修改地交付给用户。例如，允许头像最大为200kb，在诸如提交列表之类的页面上，可以一次显示20多个头像。如果每个平均大小为100kb，即20mb图片数据，则将大大降低页面加载速度。

为了提高性能，GitLab现在自动将头像的大小调整为页面上使用的大小，从而大大减少了呈现所需的内容大小。在测试页上，内容大小减少了10倍。这不仅使页面加载速度更快，而且使用的网络带宽也更少。

忙碌状态指示

通过状态更新，用户可以与他们的团队共享个性化的状态消息和表情符号。新版本中通过忙碌指示器将这一步骤进一步推进，使用户可以清楚地显示什么时候他们无法进行更多工作或需要一些时间来集中精力。

改进了组成员列表的用户体验

新小组成员列表已使用睡衣设计系统重新设计。新的体验包括更具描述性的术语，新的布局，所有列的标题，关键数据元素的工具提示等等。新的体验可帮助组管理员快速识别有关其组成员的关键属性，从而更有效地进行组管理。

按公告板和问题列表中的迭代过滤（STARTER及以上）

新的改进使用时间表来计划和跟踪GitLab中的工作，现在可以按迭代筛选问题列表和公告板。例如，使用迭代进行两周冲刺的团队现在可以将范围问题列表或公告板用作特定冲刺中目标真相的单一来源。

从问题列表中跟踪问题的健康状况（ULTIMATE）

在管理大量运行中的问题时，可能很难跟踪它们的健康状况，尤其是当跨多个Epic工作时。新版本中，可以在问题列表UI中查看问题的健康状态，从而可以快速查看工作的当前状态。以后的迭代中将会添加过滤器。

配置从静态站点编辑器上传的图像的目标

GitLab 13.6引入了从静态站点编辑器直接上传图像到项目的功能。从计算机上传的图像包含在结果合并请求中，上载资产的默认目标是source/images目录。但是，根据项目的结构，这可能不是想要图像的位置。

配置文件.gitlab/static-site-editor.yml可以自定义编辑器的行为。将条目设置为image_upload_path资产目录的绝对路径将使”静态站点编辑器”知道要将图像存储在项目中的位置。

按环境和部署时间过滤合并请求

现在，可以按环境和部署时间筛选合并请求（除了现有的按部署ID筛选的功能之外）。现在可以找到与环境名称，部署ID匹配或在给定时间之前或之后部署的合并请求。结合使用这些过滤器可以帮助确定在指定时间范围内已部署到环境的内容。

在存储库档案中包含Git LFS文件

Git大文件存储（LFS）是Git处理大文件的解决方案之一。它使用文本指针替换大文件，同时将文件内容存储在远程服务器（如GitLab）上。它允许开发人员使用Git对非常大的文件进行版本控制，并使Git在本地主机和服务器之间的操作快速而高效。

从GitLab下载包含LFS文件的项目的源归档文件，该文件用于导出指向文件的指针而不是文件本身。这使归档文件更小，但是归档文件无法保存存储库的完整快照。拥有不完整的存储库通常意味着需要更多的人工工作来单独添加这些LFS文件，以准确导出存储库。

GitLab 13.6现在将导出LFS文件，而不是指向文件的指针，从而可以无缝导出存储库的内容。

VS代码中的问题和合并请求

问题是合作的真相之源，需要采取哪些措施。回顾用户故事，设计和关于该问题的讨论，涉及在编辑器和浏览器之间进行切换。合并请求是提供反馈的地方，引用该反馈并继续进行更改，需要在浏览器和编辑器之间进行相同的上下文切换。

减少工具之间上下文切换的摩擦，可以更有效地对项目进行更改。使用GitLab Workflow的3.6.0版本，可以直接在VS Code中获得问题和合并请求，以方便访问和协作。可以查找问题并合并分配或创建的请求，然后直接在VS Code中打开这些请求。这样可以快速访问所需的信息，并可以直接对问题进行响应并通过注释合并请求。该功能是VS Code中启用更完整的”合并请求”审阅的第一步。

唯一的设计标识符

目前，所有设计都针对问题，并且具有包含问题ID和设计文件名的URL。这对设计管理的体系结构有很多限制，因为不能引用设计IID（内部标识符）字段。

尽管该功能本质上是非常技术性的，但它为在GitLab中的更多位置使用设计奠定了基础。通过独特的IID，可以将设计与MR，Epic和项目级别相关联。

包括多个CI/CD配置文件作为列表

此前，在使用include:file语法将多个文件添加到CI/CD配置时，必须为每个文件指定项目和引用。在此版本中，现在可以一次指定项目，引用并提供文件列表。这样可以避免重复，并使管道配置不那么冗长。

即使管道失败也显示覆盖率数据

作为项目维护者，可以使用徽章显示项目的当前测试范围。不幸的是，如果管道花费很长时间，具有手动步骤或分支映射到徽标的失败，则覆盖范围将显示为unknown。

使用coverage徽章，管道不必完全成功就可以显示值，从而更容易一目了然地查看状态。可以对项目的测试覆盖率值充满信心，例如在手动发布步骤之前，而不必深入研究工作清单。

单元测试报告UX改进

单元测试报告是查看管道中测试结果的一种好方法，但是存在大量痕迹可能会使页面非常长且难以导航。由于在报告页面上未显示测试文件名，因此也可能很难在单元测试报告中找到要检查的测试。

使用GitLab 13.6，可以在页面上找到单元测试报告文件中的文件名，以便于查找。同样，跟踪的内容也将从主列表中删除，并在易于访问的模式窗口中提供，从而大大提高了列表的可用性。

npm项目级接口与npm命令

使用程序包注册表发布和共享Node程序包时，可以选择使用实例或项目终结点。当同一组中有几个软件包时，项目终结点是最好的。当在不同的组中有许多软件包时，实例端点是最好的。

这个问题一直是该项目端点不支持许多常见的NPM命令，其中包括npm dist-tag，npm add，和npm view。解决方法是，必须publishConfig在每个中指定一个package.json。尽管这是一个可行的解决方法，但它有一些缺点：

它增加了发布包的难度，因为必须将每个包都配置为发布到项目注册表。

它使自动化变得更加困难。例如，可以在中替换环境变量.npmrc，但在中则不能package.json。因此，必须在中将GitLab项目ID硬编码package.json。

它不符合那些不习惯该工作流程的开发人员的期望。

为了解决这些问题，所有受支持的接口包括用于实例和项目级别的接口，现在可以使用.npmrc来配置注册表了。不再需要publishConfig在每个中添加和维护package.json。例外情况是：

上传终结点必须在项目级别。它不能处于实例级别，因为后端会在没有组或项目的情况下收到上载请求，并且不知道将包存储在何处。

压缩包端点保留在项目级别。在期间npm install，npm查询tarball URL。程序包注册表只需要答复该位置即可，该位置可以在任何地方。为简化起见，目前其保留在当前位置：在项目级别。

合并请求小部件中可用的覆盖率指导的模糊测试工件（ULTIMATE）

覆盖率指导的模糊测试结果现在显示在安全性结果中，以及合并请求中的其他安全性扫描结果。这样，可以快速查看模糊测试是否发现了问题，获取有关问题的详细信息，以及在合并代码之前下载在本地重现问题所需的相关工件。

用于Java覆盖率指导的模糊测试的新模糊引擎（ULTIMATE）

正在引入一个新的模糊引擎，用于Java覆盖率指导的模糊测试。这是在管道中运行模糊测试的基础引擎。新引擎将被调用， 并且可以通过–engine javafuzz在管道文件中进行指定来使用。

建议javafuzz在以后的现有JQF引擎上使用新引擎。新引擎支持Java Spring应用程序，希望它会很有帮助。

Gitlab Runner 13.6

同期，还发布了GitLab Runner 13.6。GitLab Runner是一种轻量级，高度可扩展的代理，可运行构建作业并将结果发送回GitLab实例。新增加功能包括：

添加Kubernetes Volumes子路径支持。

添加Kubernetes运行程序allowPrivilegeEscalation安全上下文配置。

改善功能标记后的工件/缓存性能 FF_USE_FASTZIP。

在config.toml位置设置服务入口点和命令。

在自定义执行程序中管理驱动程序定义的作业变量

限制最大Docker Machine配置率。

使用GitLab Kubernetes代理安装Runners

自定义GitLab Runner的用户可以使用GitLab托管应用或手动安装来设置Runner。尽管托管应用程序易于使用，但对于高级用例而言，这种方法并不灵活，并且手动安装未与GitLab集成，对用户意味着维护任务。GitLab Kubernetes代理可用于将任何GitLab项目转换为Kubernetes管理项目，因此创建了示例存储库和文档，展示如何使用该代理安装GitLab Runner，从而为用户提供了一个以GitLab为中心的集成的GitOps工作流程。

Bug修复

使用Azure Blob存储修复大型缓存上传。

GitLab Helm chart改进

Webservice和Sidekiq容器请求的默认资源已大大增加，以更好地表示消耗的资源。此项更改旨在防止部署遇到内存问题，尤其是在负载不足的情况下。请确保集群中有足够的内存和CPU可用，否则GitLab可能无法启动新的资源请求。

现在，Sidekiq需要更多的资源，2G的内存（而不是650M）和几乎完整的内核。

Webservice请求额外的1GB RAM，总计2.5G。

NGINX控制器的默认副本数已从3更改为2，以减少一些资源消耗。

Omnibus的改进

新增加其他身份验证选项pgbouncer支持，包括scram-sha-256。以前支持该auth_type配置，但已对其进行了硬编码以仅使用md5。

默认的一组postgres_exporter指标已更改，以减少Prometheus的总体负载。默认情况下，pg_stat_user_tables是现在禁用，节省了大约9500指标。

git已更新至2.29.0，ruby到2.7.2，rake到13.0.1，registry到2.11.0-gitlab，prometheus至2.22.0和grafana7.3.1。

GitLab 13.6包括Mattermost 5.28，它是开源的Slack替代品，其最新版本包括产品内通知以进行产品更新，等等。

安全和合规性审计

为提交SHA生成监管链报告（ULTIMATE）

在13.3中，发布了组中所有合并提交的监管链报告。经过社区反馈意见，新版本中增加了基于初始提交SHA导出报告的支持。现在，在导出此报告时，将可以选择输入提交SHA，然后将生成特定于该提交的产销监管链报告。

针对Rails漏洞的新SAST严重性数据

当安全扫描分析仪获得时，GitLab静态应用程序安全测试将提供已识别漏洞的严重性数据。最近更新了Brakeman分析仪，以增加对严重性数据的支持。该数据将有助于增加安全批准规则的可用性和准确性，因为更少的漏洞将报告”严重”。未来版本将增加其他分析器缺少漏洞元数据的功能，并添加一种机制，以允许自定义漏洞元数据，使组织能够定制结果以匹配其风险状况。

新漏洞趋势图（ULTIMATE）

长期以来，基本的漏洞趋势可视化在Group Security仪表板和Instance Security Center上可用。但是，项目安全仪表板缺少这些，使得随着时间的流逝，很难快速了解任何项目级别的漏洞数量和类型趋势。

新的漏洞趋势图可在项目级别提供所需的可见性。另外，由于它是交互式的，因此该新图表甚至比现有的组和安全中心可视化功能更强大。只需单击一下即可打开或关闭严重性趋势线，仅显示所需要的数据。还可以更改时间范围以查看最多一年的数据。趋势图是动态的，因此可以实时更新以反映的更改。

包含此图表后，还将注意到，单页的Project Security仪表板现在已分为专用的图表页面和漏洞列表页面，分别镜像了组和实例安全中心的布局。”漏洞报告”页面包含先前在项目安全仪表盘下的所有功能。”安全仪表板”页面将保留，但现在将包含新的漏洞趋势图。分离这些功能，提供了一个专用空间，可用于将来扩展项目级别的安全指标和可视化。

支持禁用预先存在的SAST规则（ULTIMATE）

GitLab静态应用程序安全性测试（SAST）现在支持禁用预定义的检测规则。通过更改漏洞检测默认值，组织可以定制安全扫描结果。禁用预定义规则将排除无关的漏洞发现，这将有助于减少误报并提高安全门（如合并请求安全批准规则）的准确性，并减少安全仪表板中报告的漏洞数量。要禁用默认规则集，请将.gitlab名为的新文件添加到文件夹中，该文件sast-rulesets.toml包含正确表示法的自定义项。可以了解有关此文件格式的更多信息，并在SAST自定义规则集文档中查看示例。旨在提供其他改进，例如.gitlab-ci.yml将来在文件中导入自定义规则集。

使用URL路径列表指导DAST扫描（ULTIMATE）

GitLab中的DAST Web测试始终依赖于成功的Spider会话来爬网站点并找到DAST扫描仪应测试的页面。这在很多情况下都有效，但是当一个站点具有隐藏的页面，一个站点的各个部分未相互链接或者蜘蛛网达到停止搜索页面的时间限制时，这可能会引起问题。如果由于处于开发实例或其他任何情况下而导致站点的响应时间很慢，则最后一种情况在扫描漏洞时会大大减少DAST测试的覆盖范围。

为了减少与抓取相关的问题，并允许用户精确控制在DAST扫描期间测试站点的哪些部分，新引入了一种使用URL列表指导扫描的方法，而不是DAST蜘蛛。使用新变量DAST_PATHS，可以在DAST_WEBSITE变量中指定的网站内包含路径列表，以供扫描程序使用。该逗号分隔的列表将作为指南，并允许覆盖蜘蛛可能找不到的页面。这也将允许使用现有的站点地图（以逗号分隔列表的形式导出），以确保DAST扫描覆盖要测试的每个页面。

项目安全性仪表板中的管道状态（ULTIMATE）

项目安全仪表板为安全和工程团队提供了集中管理漏洞的场所。由于这些报告基于默认分支的最新成功管道扫描，因此了解结果是否最新非常重要。以前，无法从这些页面确定最新默认管道扫描的时间或状态。这需要导航到”管道”列表并挖掘相关信息。

现在，当最后一个默认管道完成时，可以在Project Security仪表板的顶部看到。方便地提供了指向相应管道页面的链接。并且，如果发生任何管道故障，可以看到明确指出的故障数量。故障通知会将直接带到管道页面的”失败的作业”选项卡。解决故障情况后，运行新管道将更新该项目的漏洞数据以及安全仪表板上的新管道状态区域。

支持泄露机密的后处理

GitLab在线仓库现在支持用于秘密检测的后处理hook。这些可用于执行诸如通知发布机密的云服务之类的操作。云提供商可以确认凭据并立即采取补救措施，例如吊销或重新发布新机密，并向泄露的机密通知所有者。后处理工作流程因受支持的云提供商而异。在此初始版本中，GitLab将提供对Amazon Web Services（AWS）机密的支持。

使用专用的签名密钥进行CI_JOB_JWT Vault集成

在GitLab，安全至关重要。确保依赖的功能保持最新状态，不仅可以提供最新，最出色的功能，还可以确保安全，保护并保护敏感数据。为了提高整体安全性，现在可以为HashiCorp Vault JSON Web令牌（JWT）身份验证方法使用专用的签名密钥，并放心知道该JWT无法用于通过OpenID Connect模仿其他用户。

将合并请求导出为CSV

许多组织需要记录变更（合并请求）和有关这些事务的数据，例如谁编写了MR，谁批准了MR，以及何时将该变更合并到生产中。尽管不是详尽的清单，但它突出了可追溯性的重复主题以及从GitLab导出此数据以满足审计或其他监管要求的需求。

以前，需要使用GitLab的合并请求API使用自定义工具来编译此数据。现在，可以单击一个按钮，并接收一个CSV文件，其中包含所需的必要监护权信息链。

生成代码质量的HTML报告

代码质量报告为提供了有关在当前分支上发现的有关代码质量违规的各种信息，但是它们的格式不容易阅读。

现在，此报告已作为.html文件提供，因此可以更轻松地查看项目中的代码质量违规并确定影响。

性能改进

GitLab 13.6中针对问题，项目，里程碑以及其他方面进行了性能改进。包括：

适用于大型团体的Faster Packages API。

标记的性能更高的清理策略。

通过缩小图像尺寸来减少网站占地面积。

使用最多的CACHE SQL调用来调查和减少端点。

代码片段：使用startupJS预获取GraphQL请求。

消除阻止问题关系的复杂性。

Bug修复

13.6版本值得注意的错误修复包括：

Packages/Compose：不完全支持语义的问题；

在Packages mobile上看不到多个标签的问题；

部署令牌write_package_registry也应具有读取权限；

价值流分析：作者和受让人标签不起作用；

价值流分析：已删除的价值流在下拉菜单中保持活动状态；

代码质量合并请求小部件使用合并的管道显示不相关的数据与管道；

Web IDE：使用Monokai主题在Web IDE中无法读取搜索文本颜色；

SAST配置用户界面：SAST_DEFAULT_ANALYZERS用默认值错误写入；

如果里程碑链接到该版本，则无法更新；

永久释放资产链接：找不到（404）；

在私有unner上使用release-cli时超时；

部署状态标志未正确显示；

dotenv变量在网桥作业中不可用；

interruptible 不会取消子管道；

markdown中的一些unicode字符被转换为图片；

使用YAML呈现的Markdown无法处理UTF8 BOM；

专注于问题”标签”选择器；

问题标签选择滚动太多会导致可用性问题；

描述包含代码块时，快速操作不起作用；

修复失败的健康状态更新；

删除iids Epic的重复；

修复Service Desk电子邮件中附件的链接；

将组级标签与Service Desk模板一起应用；

工作流：规则变量无法从上游访问传递的变量并触发变量；

作业输出中缺少”before_script”/”script”部分；

artifacts:expire_in 在.gitlab-ci.yml中实际上不起作用。

功能删除

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

变更日期：2021年1月22日

目前GitLab支持应用程序日志的文本，JSON和logstash日志格式。

用于访问日志的文本，JSON和组合日志格式。未来计划弃用logstash和组合格式，仅使用两个选项文本（用于开发）和JSON统一应用程序和访问日志的格式化程序。

删除Container Registry日志Hook

变更日期：2021年1月22日

容器注册表当前支持只能用于电子邮件通知的日志记录Hook。现在基于日志条目的警报通常由单独的工具处理。据统计，GitLab用户都不依赖此功能。此功能的实现与底层的日志记录库紧密耦合，在不影响可用功能的情况下切换依赖关系的能力的限制。为了简化注册表功能和配置，将删除对日志记录Hook的支持。

删除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.minidle（最小空闲连接数）和redis.pool.maxlifetime（可以重用连接的最大时间）设置。

删除Bugsnag的Container Registry支持

变更日期：2021年1月22日

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

删除NewRelic Container Registry支持

变更日期：2021年1月22日

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

不再支持TLS 1.0和1.1 Container Registry支持

变更日期：2021年1月22日

出于安全原因，不支持TLS 1.0和TLS 1.1，并已从GitLab中删除了对它的支持。将对当前支持1.0（默认），1.1、1.2和1.3的GitLab容器注册表进行同样的操作。且默认为1.0。

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

删除对Docker注册表API v1的支持

变更日期：2021年1月22日

GitLab将于2021年1月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。

删除Kubernetes 1.14的支持

变更日期：2020年12月22日

GitLab将于2020年12月22日弃用Kubernetes 1.14支持。

删除对Elasticsearch 6.7的支持。

变更日期：2021年2月22日

Elasticsearch 6.7将不再与GitLab 13.9及更高版本兼容。

所有使用Advanced Search的客户都应计划升级到Elasticsearch 6.8或更高版本，然后再升级到GitLab 13.9。如果当前运行的GitLab版本低于13.2。

Windows默认运行shell改为pwsh

变更日期：2021年6月22日

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

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

变更日期：2021年6月22日

在GitLab Runner 13.3中，添加了一个从加入/usr/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中，将删除功能标记。

删除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中，将删除转换。

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

变更日期：2021年6月22日

在GitLab Runner 13.2 转译step_script到build_script被添加到自定义执行。在14.0中，”build_script”阶段将替换为”step_script”。

Sidekiq群集队列选择器配置选项重命名

变更日期：2021年5月22日

GitLab包含大量的后台作业队列。一些管理员可能希望拥有多个后台作业流程，每个后台流程都运行不同的工作负载。

以前，仅支持按名称指定为特定进程处理的队列，或者使用实验性选项允许按属性选择队列。experimental_queue_selector 将重命名为queue_selector。在GitLab 14.0之前experimental_queue_selector将继续工作。

Web应用程序防火墙（WAF）

变更日期：2020年11月22日

GitLab 13.6不推荐使用GitLab的Web应用程序防火墙（WAF）。由于这是一项重大更改，因此将于2021年5月22日在GitLab 14.0中从产品中删除WAF。GitLab的WAF具有建筑设计固有的局限性，因此很难满足WAF的传统要求。通过弃用和删除WAF，GitLab将能够集中精力进一步开发产品中可以为用户提供更多价值的其他领域。当前依赖GitLab WAF的用户可以继续使用独立于GitLab的免费和开源modsecurity项目。

删Opsgenie的直连

变更日期：2021年1月22日

通过HTTP接口集成与Opsgenie和其他警报工具进行更深入的集成，以便可以在GitLab界面中查看警报。因此，在2021年1月22日13.8版之后，将不建议使用警报列表中指向Opsgenie的上一个链接。

升级更新

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

对于GitLab helm chart用户，增加了资源请求以更好地表示负载下的消耗量。鼓励管理员检查更改，并确保其群集具有足够的可用资源，否则可能导致服务无法启动。