GitLab 12.10 新增加AWS CI自动扩展、需求管理、Jira问题导入等

虫虫安全 08-18 310

前言：

目前你们对“nginx图片缩略图”大体比较注重，我们都需要剖析一些“nginx图片缩略图”的相关内容。那么小编也在网络上汇集了一些对于“nginx图片缩略图””的相关知识，希望兄弟们能喜欢，朋友们一起来了解一下吧！

按照日常惯例，GitLab 官方博客宣布了新月度版本12.10的发布。该次升级主要在安全合、CI加速、高效项目管理方面做了改善。请跟着虫虫一切来学习该版本的功能。

概述合规更容易

在大多数大型组织中，合规性是一个常见的挑战，团队和项目需要证明他们遵循组织的流程和程序并交付了实际"需要"的内容。项目是否真正满足了业务需求是一个普遍的问题，从12.10开始， GitLab中将需求管理作为一个单独的类别进行交付，帮助团队定义，跟踪和管理业务需求。另外，GitLab 12.10中加强了项目和发布合规性证据证明，不再需要使用脚本对比发布证据随时间的推移，项目"合规性"证明。新的项目合规框架标签使组织可以轻松地指出需要特定项目才能符合特定合规性框架。

关于合规性框架，为了帮助需要进行HIPAA审核和合规性的项目，新的HIPAA审核协议项目模板为他们提供了一个良好的开端。通过改进的HashiCorp Vault集成，有助于项目的安全策略合规。

减少周期时间并加快AWS交付

随着持续集成，CI执行可能会成为一个瓶颈，会减慢交付速度。所以，很长一段时间内一直支持自动缩放GitLab CI的运行。在GitLab 12.10中，Gitlab将AWS Fargate的自动扩展功能扩展到自动扩展运行器，可以有效扩展以满足需求。可以使用预定义的AWS部署变量将应用程序配置为部署到AWS上，变得更快，更轻松，GitLab在其中添加了AWS部署变量，还有助于进行格式验证。

高效管理项目

管理多个项目和相关问题可能很难。对于很多跟踪信息，很难知道哪里可能存在问题。在GitLab 12.10中，团队可以轻松跟踪和共享问题的健康状况，从而可以轻松的从可视化Epic整体健康状况。另外新增加将问题从Jira导入到GitLab的功能，使团队可以花费更少的时间在工具之间进行切换，而将更多的时间集中在构建出色的软件上。

GitLab 12.10主要功能改进在GitLab中创建和查看需求（ULTIMATE）

GitLab中新增加了需求管理功能，在第一版的功能中只支持用户创建和查看项目级的需求。

开发团队中常见的一个问题与外部需求管理工具、多个工具链和工作流的协调和集成。通过提供将所有需求，设计，代码和测试在一栈环境中实现可以减少这样的困惑。的机会，我们相信单个应用程序的强大功能。GitLab推出需求管理功能，将逐渐实现对所有工作流的整合和每个工作的可追溯性，通过创建一个无缝的工作流以直观地展示完整性和合规性。

和HashiCorp Vault集成

在新版本中，GitLab添加了对轻量级JSON Web令牌（JWT）身份验证的支持，实现与现有的HashiCorp Vault集成，可以利用HashiCorp的JWT身份验证方法无缝地为CI/CD作业提供认证凭据，而不用在GitLab中手动密码变量。

Epic和问题健康跟踪（ULTIMATE）

跨多个组和项目管理多个Epic是困难的。为了帮助用户跟踪项目和进行中的工作，新版本中通过对Epic树着色，上显示红色、琥珀色或绿色的健康状况来报告并快速响应单个问题和Epic的健康状况。将问题的健康状态分配为"正常"（绿色），"需要关注"（琥珀色）或"有风险"（红色），并在Epic级别查看健康状况的汇总报告。

Jira问题导入

此前将Jira问题引入GitLab的唯一方法是手动导入，要用CSV导入器或手动执行迁移实用程序。GitLab 12.10新增加了一个MVC，可自动将Jira问题导入GitLab。可实现从Jira到GitLab的无缝导入：

在的GitLab项目上设置Jira集成，单击项目的Issue List顶部的import图标，然后选择Import From Jira。

在AWS Fargate上自动缩放GitLab CI作业

GitLab Runner自动扩展功能通过配置新的云托管虚拟机来响应CI作业需求。尽管这种自动上下虚拟机实例的模型对于特定用例已经足够，但客户还希望利用云容器编排解决方案的功能来执行GitLab CI/CD作业。新版本中可以使用GitLab的AWS Fargate Driver MVC版本在AWS Fargate上自动缩放GitLab CI。

借助这种新的自动缩放模式，GitLab的AWS Fargate驱动程序使用用户定义的容器镜像在Amazon弹性容器服务（ECS）上的单独且隔离的容器中自动运行每个构建。

易于配置AWS部署变量

在部署到AWS时，应尽可能方便地应用必要的环境变量。新版本中可以从环境变量键列表中使用"WS_ACCESS_KEY_ID"，"AWS_SECRET_ACCESS_KEY"和"AWS_DEFAULT_REGION"的选择预定义变量。还有一些输入的经过验证的变量，以确保以有效格式输入它们。

在版本发行中链接运行手册和资产

发布和构建通常需要在GitLab之外进行多项活动，以有效地发布版本。GitLab致力于使"发布"页面成为有关发布的所有内容的唯一真实来源。新版本中添加了将运行手册链接到发行版资产的功能，现在可以轻松地跟踪所有这些相关活动，并了解目前的进度。

GitLab状态页（ULTIMATE）

当服务中断或降级时，最重要的是要对其进行修复。同时，必须向客户和业务干系人更新修复进度。用户依靠状态页来确认提供者是否了解问题并了解如何做。当发生突发事件时，知道当前正在采取的步骤可以激发信心。它可以帮助人们选择应对事件的方式。

在新版本中，新增加了GitLab状态页。在事件发生期间使用户，客户和利益干系人将通过该功能了解情况。

首先显示的是GitLab实例上专用事件管理项目中的问题的信息，并将其发布到公共状态详细信息页面。更多信息以后会陆续扩展和增加。

构建、发布和共享Python软件包到GitLab PyPI仓库库（PREMIUM及以上）

Python开发人员需要一种机制来创建，共享和使用包含使用这些软件包的项目中包含已编译代码和其他内容的软件包。PyPI是一个由Python Packaging Authority维护的开源项目，他用来定义、创建、托管和使用Python软件包标准。

在GitLab 12.10中，提供了内建的PyPI仓库库。开发人员可以直接在GitLab发布Python软件包。通过与PyPI集成，GitLab将提供一个集中的位置，以在与源代码和管道相同的位置存储和查看这些软件包。GitLab PyPI仓库库以及对其他软件包管理器格式的支持将移至开源。

组级活动概述MVC（STARTER及以上）

开发主管和GitLab管理员通常希望了解其团队中如何使用GitLab。在该MVC中，在组登录页面上看到三个计数：在过去90天内，合并请求，问题和添加到该组的用户数。该功能当前以Beta版本发布。

首先按最新活动查看问题和MR提要

问题是GitLab中进行协作的主要工具之一。从最早到最新的讨论和系统注释的默认顺序对于某些用例（例如了解给定问题的历史记录）非常有用。但是，当团队处于分类和故障修复模式时，该显示顺序显然不太适合，因为需要滚动到问题末尾才能查看最新更新。

最新版本中支持可以颠倒默认顺序，并与活动Feed互动，顶部的是最新项。问题和 MR的首选项通过本地存储分别保存，并自动应用于查看的每个问题和MR。

设计缩略图（PREMIUM及以上）

上传到问题的设计的文件大小可能非常大。加载这些文件可能需要很长时间，尤其是在一个Issue中有多个设计时。在新版本中，现在会自动生成"设计"缩略图，并使用它们来缩短"设计"选项卡的加载时间。随着我们继续构建设计管理功能，这还将使我们能够缩短在GitLab其他部分中的设计加载时间。

通过在GitLab官网测试，对一个2.6MB样图主页，分辨率为1222px x 5113px，生成缩略图图后，大小仅仅为0.018MB，为原来的千分之一。

文件扩展名的仓库文件小图标

查看存储库中的文件时，GitLab现在会基于文件扩展名显示一个图标。不同的文件类型使用不同颜色和形状的图标实现文件列表类型的快速识别。

该改进还统一了仓库视图，Web IDE和合并请求中文件树之间的图标样式保持一致。

带有内置静态站点编辑器的项目模板

使用GitLab Pages托管静态网站是网站发布运行的最简便方法。但是，编辑发布静态站点的内容通常需要设置复杂的本地开发环境，对基础项目体系结构的理解以及对Markdown语法的熟悉。对大多数人来说，这是一个障碍。

GitLab新版本中，提供了一个新的项目模板，该模板创建一个静态网站，最初支持Middleman，该网站预先配置为可托管在GitLab页面上，并具有可以在新的简化的"静态站点编辑器"中进行编辑的内容。部署网站后，只需单击每个页面上可见的"编辑此页面"链接，这将启动新编辑器，该编辑器将删除多余的界面，并完全专注于页面内容。完成后，只需单击一下即可生成一个新分支和一个合并请求以进行更改。

使用Deploy令牌读取和写入GitLab软件包到容器注册表

部署令牌使可以访问组和项目的存储库以及容器注册表。但是，已定义的范围read_repository不允许向GitLab容器注册表授予推送访问权限。结果，DevOps团队常使用不安全或昂贵的基于用户的解决方法。

在GitLab 12.10中，GitLab部署令牌支持更精细的权限。可以为Container Registry设置读取或写入访问权限。可以从GitLab应用程序中或使用API创建和管理Deploy Token。

在组级别查看Container Registry中的Docker镜像

使用GitLab容器注册表时，拥有所有Docker镜像的跨项目视图非常重要。直到最近，用户界面仅在项目级别可用。这种低效的工作流程导致团队之间缺乏协作和Docker镜像共享。

在12.10中，现在可以在GitLab应用程序中查看小组的所有图像。现在，可以在一个地方共享，发现和管理所有图像。

独立的ECS任务创建

作为Cloud Deploy Docker镜像的一部分，Gitlab捆绑了一个脚本，可以在管道中利用该脚本来简化ECS部署的任务创建。这可帮助在部署作业中移动模版代码，并简化CI/CD配置。

GitLab UI删除环境

在GitLab UI中而不是API管理环境非常有必要。将环境管理扩展到UI可以节省时间，并支持用户在GitLab前端中度过一天。

自定义指标

了解系统性能通常始于监视传达有关组件的运行状况和性能的指标。每个开发团队都需要这些功能，我们希望我们的指标解决方案可广泛提供给所有使用GitLab新版本中监控阶段的自定义指标从GitLab Ultimate迁移到GitLab Core全面免费。从GitLab 12.10开始，所有用户都可以在GitLab UI中使用Prometheus添加和显示他们收集的任何度量。

可用的Sidekiq群集

Sidekiq Cluster允许启动其他Sidekiq进程来运行后台作业，并提供方便的选项来选择要处理的一组特定的作业队列。这些选项可以改进Sidekiq队列的管理，并可以继续扩展大型实例。

此功能需要在STARTER及更高版本中可用。作为2020年礼物的一部分，从GitLab 12.10开始，现在在Core中免费可用，在GitLab 13.0开始默认启用它。

GitLab告警

监控和观察系统及应用程序性能的关键部分时候发出告警，该告警可在发生问题时发出。没有告警，就无法关闭DevOps循环并有效地响应已突破关键阈值的服务。作为2020年礼物的一部分，Gitlab监控告警从GitLab Ultimate移至GitLab Core全面免费。从GitLab 12.10开始，所有用户都可以从指标仪表板上的图表创建IT警报，并通过通用REST端点在GitLab中接收警报。

折叠问题中展开的图表

解决事件时，直接嵌入到问题中的图表可以通过在一个位置显示所有信息而不是强迫在多个位置之间跳动来节省的时间。但是，如果只想阅读文本并快速使用信息，则图表可能会令人沮丧。新版本中，可以折叠和展开图表，并在查看图表或将其从视图中删除之间进行选择。

使用条形图显示指标

在监控仪表板上添加了条形图作为新的可视化选项，以帮助以所需的方式显示指标。

开箱即用的NGINX警报，可在Auto DevOps中进行自动监控

自动监视是Auto DevOps的功能，Auto DevOps是一种预定义的CI/CD配置，使可以自动检测，构建，测试，部署和监视应用程序。

自动监视使可以在部署应用程序后立即监视应用程序的服务器和响应指标。自动监控使用Prometheus直接从Kubernetes中显示系统指标，例如CPU和内存使用情况，以及从NGINX Server显示响应指标，例如HTTP错误率，延迟和吞吐量。尽管听起来需要进行大量配置，新版本中为NGINX吞吐量和HTTP错误率指标添加了开箱即用的警报，可在使用后立即使用它们，从而减少了查看指标和执行警报所需的配置为Auto DevOps设置自动监视。

指标图表URL的时间范围

现在，在查看度量标准图表时，更新时间范围将更新图表的URL，从而使可以轻松共享或标记指向特定时间范围的链接。

Geo将对未同步存储库的HTTP（S）请求重定向到主节点（PREMIUM及以上）

Geo支持项目的选择性同步，这使系统管理员可以选择要复制到辅助Geo节点的数据子集。到目前为止，尝试访问未同步的辅助节点上的存储库的用户将收到一个错误，指出该项目不可用。这可能是由于选择性同步或由于复制滞后。这使用户感到困惑，并打乱了他们的Git工作流程。

在GitLab 12.10中，任何通过HTTP（S）向未同步的辅助Geo节点发出的Git请求都将转发到主要节点，以便用户仍然可以访问存储库。这样用户将不需要知道重复的内容或不重复的内容-Geo将尝试满足请求。在GitLab 13.0中将提供对代理SSH Git操作的支持。

在全局搜索结果中代码高亮

长期以来，GitLab中的全局搜索能够为执行的搜索返回代码结果。但是，对于用户来说，尚不清楚他们的搜索查询在返回结果中的实际位置。这样用户必须在结果中寻找这一点，并且可能错过了可能已多次返回字符串的重要结果。

现在，将会将高亮显示搜索到的每一行，以更好地指示搜索项在结果中的匹配位置。

使用Puma减少GitLab的内存消耗

GitLab正在将应用服务器从Unicorn切换到Puma，从而将GitLab的内存占用量减少了40%。效率的提高可以使GitLab管理员利用较小的内存实例，从而降低服务的运营成本。与Unicorn的单线程模型相比，通过利用Puma中的多线程支持实现了这些节省。Puma支持通常在Omnibus中可用，而Helm中是实验性的。计划使Puma成为GitLab 13.0中的默认应用程序服务器。

用户统计数据得到改善

"用户统计信息"页面为管理员提供了按角色划分的用户帐户的概述，以及所有用户，活动用户和被阻止用户的总数。GitLab计费基于活动用户数。

使用复制和粘贴将图像上传到"设计"选项卡

使用新的"复制和粘贴"功能，现在可以将剪贴板历史记录顶部的一个图像作为.png文件直接粘贴到"设计"选项卡中。此功能对于在任何问题中快速共享剪贴板中的屏幕截图特别有用。

跟踪Wiki活动

到GitLab 12.9为止，当贡献Wiki内容时，它不会影响在GitLab中的活动。在新版本中，将在项目，组和用户活动页面上看到所有Wiki贡献。现在，可以跟踪Wiki的更改。

缓存Git信息/引用

从Git存储库中获取更改时，服务器会发布存储库中所有分支和标签的列表，称为refs。在某些情况下，观察到对GitLab Web服务器的所有请求中，多达75%是对引用的请求。最好的情况是，当所有参考文件都打包好时，这是一种廉价的操作。但是，当有解压缩的引用时，Git必须遍历解压缩的引用。这会导致额外的磁盘I/O，当使用高延迟存储（如NFS）时，会很慢。

在GitLab 12.10中，info/refs通过缓存来提高引用广告的性能，并减少引用非常频繁获取的情况下对Gitaly的压力。在GitLab官网上测试此功能时，观察到读操作数比写操作数多10到1，并且中值等待时间减少了70%。对于使用NFS进行Git存储的GitLab实例，我们期望会有更大的改进。

轻松访问Container Registry命令

GitLab容器注册表用来显示一个插图，其中包含易于复制的构建和推送命令以及适用于项目的正确注册表URL。但是，将镜像添加到注册表后，命令功能将消失。

在12.10中，即使注册表不为空，现在也会显示这些Docker命令。这将使新用户的入职过程更加容易，并将提高他们对Docker命令的熟悉程度。

按名称过滤软件包注册表（PREMIUM及以上）

GitLab的Package Registry使可以在一个通用的注册表中存储多种软件包类型。直到最近，浏览软件包列表的唯一方法是更改排序顺序。这样很难有效地找到特定的程序包，尤其是如果在注册表中存储了许多程序包时。

从GitLab 12.10开始，现在可以过滤name以快速找到的软件包。

使用GitLab API从依赖代理中清除Blob （PREMIUM及以上）

GitLab Dependency Proxy允许代理和缓存托管在DockerHub上的镜像，因此可以随时在GitLab CI/CD中使用它们。在此之前还没有清除缓存的方法，这导致了额外的存储成本。

在新版本中可以用GitLab API清除组的Dependency Proxy的缓存并降低总存储成本。

Gatsby的GitLab Pages项目模板

GitLab页面本身支持最常见的静态站点生成器。在GitLab 12.10中，可以通过新Gatsby项目模板利用静态网站的最新技术，包括ReactJS，Webpack，GraphQL，现代ES6 + JavaScript以及CSS。

将指标自动嵌入到GitLab问题，并在Prometheus告警

在对事件进行分类时，图表可帮助可视化错误原因，这可以加快调查和解决的速度。在12.9中，GitLab开始自动将相关图表嵌入从GitLab配置的Prometheus告警创建的所有事件问题中。新版本中，对该功能进行了扩展，用以解决GitLab收到的所有Prometheus警报生成的问题，无论告警是在GitLab中配置还是在外部配置。

筛选搜索的Pod日志

日志无处不在，仅在可以轻松找到相关日志的情况下才有用。在GitLab 12.10中，新引入了对Pod日志的过滤搜索，使能够使用单个可伸缩的搜索栏搜索和定义Pod日志的过滤器。这取代了繁琐的终端视图，过滤器和搜索栏的组合，最终使能够更轻松地查找相关日志。

支持指标图表中的自定义间隔

有时，使用预定义的时间间隔将很难确定特定的时间段。GitLab监控仪表板现在支持自定义间隔，这使能够在选择的间隔内可视化聚合指标数据，并且能够以默认间隔可视化。

Geo管理员界面改进（PREMIUM及以上）

系统管理员需要了解其地理安装的总体状态。如果检测到复制错误，这尤其重要。在GitLab 12.10中，对Geo管理员界面进行了多次迭代改进，使系统管理员可以更轻松地诊断Geo问题，并帮助他们了解需要采取的纠正措施，例如，通过识别无法复制的存储库。

最大的变化之一是添加了一个弹出窗口，该弹出窗口显示了所有已同步，排队和失败的项目的详细分类。在可用的地方，有一个链接到详细信息页面，该链接使系统管理员可以调查单个项目。

此外，管理员界面也进行了其他一些用户体验改进：

在所有地理表格中启用实时验证

更新了地理健康状态以使其更加可见

重做了我们不复制的商品的同步状态

改进的地理节点形式错误，可提供错误原因的更多详细信息

轻松清理未使用的LFS文件

GitLab支持通过Git LFS管理项目中的大型二进制文件，例如音频，视频或图形文件。可以通过重写Git历史记录从LFS中删除这些文件；但是，未引用的文件仍会耗尽存储空间。到目前为止，删除这些未引用的LFS对象的唯一方法是删除整个项目，在许多情况下这不是一个选择。因此，用户可能会遇到存储限制的情况，并意识到他们在不再需要或不需要的LFS对象上使用了大量存储，而没有明确的前进路径。

为了适应，新版本中添加了两个Rake任务

gitlab:cleanup:orphan_lfs_file_references和gitlab:cleanup:orphan_lfs_files，

它们允许从单个项目中删除LFS文件。Rake任务可以在逐个项目的基础上运行，并根据需要进行计划。

进阶全局搜寻索引大小减少约50%（PREMIUM及以上）

以前，由于所需的Elasticsearch索引的大小，将GitLab中的Advanced Global Search扩展到非常大的实例一直很困难。该索引由搜索数据和配置组成，仅部分使用。已经重新评估了需要为哪些内容建立索引的用法，并更新了index_options"高级全局搜索"配置的。在GitLab官网上，生产Elasticsearch Index减少了近50%。此项更改将使使用Advanced Global Search的入门变得更容易，并帮助节省在GitLab中运行Advanced Global Search时的运营开销。

默认使用PostgreSQL

GitLab提供的PostgreSQL的默认版本现在为PostgreSQL11。对于新安装以及不使用HA或Geo的现有安装的升级，默认情况下将自动使用PostgreSQL 11。有关Geo和HA的安装，请参阅12.10升级说明(文末)。在使用10K用户参考体系结构的GitLab性能测试，结果显示 PostgreSQL 11每秒处理的请求数比PostgreSQL 10多出7%，并且显示了合并请求讨论终端的CPU使用率减少了20%。

请注意，自GitLab 13.0起，不再支持PostgreSQL 9.6和PostgreSQL 10。在升级到13.0之前，需要先升级PostgreSQL版本。

如果使用Geo架构，请记住，由于需要在辅助群集上重新同步数据库，因此在不中断Geo辅助服务器的情况下无法进行主要的PostgreSQL更新。Geo升级文档中提供了针对Geo的特定步骤。如果使用Helm安装，则需要手动切换到PostgreSQL 12.10版。

切换到GitLab模式的普通SQL

GitLab 12.10已经从利用切换schema.rb到structure.sql用于管理数据库模式。切换到纯SQL structure.sql允许GitLab使用PostgreSQL特定的命令，例如分区。

贡献者和管理员在需要进行迁移时可能希望了解更改。更改为structure.sql将会自动执行，并且不需要任何操作。

Omnibus的改进

GitLab PackageCloud存储库的GPG签名密钥已过期，已经用新密钥替换。所以，需要已经在其计算机上配置了GitLab软件包存储库，通过apt，yum或zypper使用的现有用户，必须要重新获取并添加新密钥，才能继续从GitLab软件包存储库安装或更新软件包。

GitLab 12.10引入了Mattermost 5.21，其最新版本包括与AWS，GitLab和CodeShip的ChatOps集成。此版本还包括安全更新，建议从早期版本进行升级。

Omnibus GitLab现在默认安装新版本的PostgreSQL 11。对于升级，如果未配置HA和Geo，则默认为PostgreSQL 11。

GitLab Runner 12.10

同期也发布了GitLab Runner 12.10。新增加功能包括：

支持raw变量：此功能支持从GitLab检索变量的原始标志。标志的值是未解释和按字面意义对待变量。

bug修正包括：

修复有时作业失败，并且运行器生成no such file or directory错误。

修复当Runner主机名包含下划线（_）时，Docker机器无法在AWS上创建自动缩放的Runner实例。

修复有时作业在Google Kubernetes Engine（GKE）上失败，并且Runner生成error dialing backend: EOF错误。

修复作业失败，容器名称已经在使用Docker executor的错误。

修复作业因Docker executor失败而出现" No such container"错误。

修复包含下划线（_）的生成容器主机名不符合RFC1035。

修复包含下划线（_）的运行程序主机名不符合RFC1035。

修复Helm图表配置中出现拼写错误，导致Runner无法使用先前定义的Google secret。

更多详细的信息，请参考GitLab Runner CHANGELOG中。

性能改进

在GitLab 12.10中，提供了问题，项目，里程碑等方面的性能改进包括：

具有大量问题的里程碑页面不再超时；

合并请求讨论API不再随着评论数而降低；

问题创建具有可自定义的速率限制；

使Rails.cache和Gitlab::Redis::Cache使用相同的池；

向GraphQL组端点添加问题；

从GraphQL EpicType删除N + 1个查询；

通过流串行器导出，引入Writer抽象；

Redis中启用缓存Elasticsearch的检查。

安全和审计增强的安全工作流程，可用于离线环境（ULTIMATE）

GitLab安全扫描仪需要互联网连接才能下载更新和最新签名。在脱机或连接受限的情况下自建GitLab实例，这些任务是不可以的。在GitLab 12.10中，使得在离线环境中安全扫描器变的可用。对基础扫描仪作业定义的多项调整均支持此工作流程。

脱机环境的新文档介绍了脱机环境中安全扫描所需的高级工作流程。新版本还在每个扫描仪的文档页面上添加了特定于扫描仪的说明。

通过提供对其他语言，工具和用例的支持，GitLab将在将来的版本中添加对脱机安全扫描的支持。

提供严重性级别以进行依赖项扫描漏洞（ULTIMATE）

现在，所有"依赖性扫描"分析器都支持报告严重性级别，从而使发现的风险和优先级更加容易评估。以前，并非所有语言都得到具有严重性的调查结果的支持，而某些严重性设置为Unknown，因此很难优先考虑其补救措施。

项目的合规性框架标签（ULTIMATE）

使用GitLab的组织具有决定其运作方式的公司政策和行业法规。许多客户的首要目标是确保其GitLab项目遵守受行业法规影响的公司内部政策。以前，没有一种简单的方法可以将一个项目标识为具有某些合规性要求或附加监督的项目，这是跟踪合规性状态的基本需求。

现在，可以通过导航到项目Settings区域，然后在该General部分中的Compliance framework下拉菜单中进行选择，为具有特定合规性框架的项目添加标签。此功能为将来简化项目合规性管理奠定了基础。

合规性仪表板显示最新合并的MR的管道结果（ULTIMATE）

当管理员或组所有者评估其GitLab项目的合规性时，他们需要知道所部署代码的管道状态。管道可以包含确定是否遵守组织策略的阶段或工作。到目前为止，管理员或组所有者必须调查每个项目以验证每个管道。

现在，"合规性仪表板"包含组中所有项目的最新管道状态。管理员和组所有者现在可以一眼识别出已批准和合并的MR的潜在合规性问题。

禁用DAST中的单个规则（ULTIMATE）

作为黑盒工具，DAST扫描对底层站点或应用程序体系一无所知。这可能导致用户立即知道不是可利用的漏洞的误报。例如，当应用程序体系结构中没有SQL数据库时，DAST扫描报告可能存在SQL注入漏洞。由于这个问题，GitLab 12.10支持使用DAST_EXCLUDE_RULES变量打开和关闭特定规则。这允许使用逗号分隔的漏洞规则ID列表从扫描中排除。使用此变量排除特定规则时，可以针对目标应用更好地进行扫描，以减少误报。

容器网络策略统计报告（ULTIMATE）

新版本中可以同时看到总流量和阻止流量的数据，从而可以更轻松地确定如何配置，调整和评估网络策略。

容器网络策略统计信息将显示在"安全与合规性"菜单项下的新"威胁监控"页面上。默认情况下，数据为期30天。

用于记录和阻止模式的Web应用程序防火墙（WAF）控件

为了帮助调整误报或误报的规则，可以在"操作"->" Kubernetes"页面上将WAF全局设置为"记录"或"阻止"模式。

比较一段时间内的Release证据（PREMIUM及以上）

在12.6中，GitLab引入了一种简化的方法来收集所有必要的信息，以支持Release对象中的合规性和审计工作。利用此新功能，证据收集时间戳将显示在下载证据哈希的链接旁边。这使审核员可以轻松地比较一段时间内的发布证据，而不需要脚本来收集和比较每个证据。

新的HIPAA审核协议项目模板（ULTIMATE）

借助GitLab，可以自动化高度可重复的HIPAA审核协议工作流程。manbetx客户端打不开可以利用问题和项目模板来帮助简化这些工作流程。此过程可以帮助将新问题映射到HIPAA审核协议中的每个要求。它还可以帮助的组织在GitLab工作流程中管理审核证据的收集和总体状态。

GitLab现在通过新的企业合规性模板支持HIPAA审核协议。为了帮助符合HIPAA审核要求，GitLab可以帮助创建新项目，每个项目都有180个问题映射到HIPAA审核协议。每个问题都是每个HIPAA协议的审核跟踪，并且可以帮助团队在GitLab中管理其HIPAA合规性计划时保持联系。

可选的SSH密钥有效期

注重合规性的组织需要一种方法来控制对其GitLab环境的SSH凭据访问。SSH密钥通常配置为没有到期日期。对于具有访问管理和/或凭据管理策略的组织而言，这是有问题的，这些策略要求所有访问凭据上的有效期。在新版本中，GitLab支持用户可以在GitLab UI中设置的SSH密钥的到期日期。

Bug修复

GitLab 12.10修正很多bug，其中包括：

使用GraphQL API时，合并请求不再返回空数组；

Elasticsearch集成菜单现在可以防止URL字段中出现非URL模式；

更新Elasticsearch index_options以修复复杂的搜索查询；

改善Elasticsearch设置的自动完成结果；

遇到数据库连接错误时引发异常；

具有大量问题的里程碑页面不再超时；

发行板搜索返回1和2个字母搜索的结果；

董事会列表成为组标签时不再失去其过滤器标签；

修复带有2个标签和搜索文本的列表中的史诗过滤时的异常；

创建发布API对于无效标签返回500错误；

将发行说明设为可选，并且在删除发行说明时不要删除发行说明；

使用来宾帐户的用户看不到发布；

GitLab页面的最大大小不接受值0；

在分页时不加载时释放页面。

GitLab Chart 改进

Helm Chart文档已更新，包括命令行选项和特定于Helm 3的文档链接，并着重强调了Helm 2和Helm 3之间的某些区别。

在GitLab的下一发行版GitLab 13.0中，将删除环境变量的ConfigMap条目puma.rb和unicorn.rb文件。请注意，如果过去曾经unicorn.rb通过ConfigMap（通过Helm + Kustomize）修改了，则将受到此更改的影响。

到目前为止，puma.rb和unicorn.rb文件在gitlab-webservice容器内是静态的，并被gitlab/unicorn图表中的ConfigMap项覆盖。

现在使用的Web应用程序服务器的Unicorn或Puma之间进行选择，Unicorn图表的名称将从更改unicorn为webservice。

功能弃用GitLab CI/CD管道配置模板由""取代only和except

更改日期：2020年5月22日

gitlab不鼓励使用only和except支持。该rules参数提供了更详细，更具表现力的作业执行逻辑，这些逻辑对于评估和理解不太复杂。

从GitLab 13.0开始，将使用并将转换为的Auto DevOps和Secure 配置模板。我们强烈建议定制工作模板的客户过渡，因为这两个配置选项不能一起使用。更改将影响以下作业配置模板：

Build.gitlab-ci.yml

Test.gitlab-ci.yml

Deploy.gitlab-ci.yml

安全功能有关的 .gitlab-ci.yml模版s:

Container-scanning.gitlab-ci.yml

DAST.gitlab-ci.yml

Dependency-Scanning.gitlab-ci.yml

License-Management.gitlab-ci.yml

License-Scanning.gitlab-ci.yml

SAST.gitlab-ci.yml

使用only和对这些模板的任何自定义except都应转换为语法。在某些情况下，现有only和except逻辑无法与匹配rules。我们很乐意听到有关此rules

Auto DevOps的默认PostgreSQL

生效日期：2020年5月22日

作为更新Auto DevOps以支持Kubernetes 1.16的一部分，在GitLab 12.9中添加了Auto DevOps的启用功能，以使用PostgreSQL图表版本8.2.1。当前默认的PostgreSQL图表版本是0.7.1。在GitLab 13.0中，计划将默认的PostgreSQL图表版本从0.7.1切换到8.2.1。要保留旧的默认设置，需要将AUTO_DEVOPS_POSTGRES_CHANNELCI变量显式设置为1。要将现有的0.7.1 PostgreSQL数据库迁移到较新的基于8.2.1的数据库，请遵循升级指南以备份数据库，安装新版本的PostgreSQL并还原数据库。

Auto DevOps Auto Deploy设置值已弃用

弃用日期：2020年5月22日

由于Kubernetes 1.16启用了多种API，默认值extensions/v1beta1对于deploymentApiVersion在汽车的DevOps'设置自动部署图现在已经过时。

该deploymentApiVersion设置计划apps/v1在GitLab 13.0中更改为新的默认值。如果使用的是Kubernetes 1.9及更低版本，则需要升级Kubernetes集群以获得apps/v1版本支持。对于Auto DevOps，GitLab需要Kubernetes 1.12+版本。

项目端点的偏移分页限制为50,000

生效日期： 2020年5月22日

基于偏移量的分页限制50,000将在GitLab.com上应用，默认情况下在自管实例上将应用于/projects GitLab 13.0中的API端点。进行具有以上偏移量的API调用的集成50,000将需要切换到基于键集的分页方法，该方法可显著改善响应时间并减少GitLab服务器上的负载。自建实例将能够将限制自定义为所需的值。

为了提供优化的性能，基于键集的分页仅提供基于project的排序id。如果偏移量保持在限制以下，则需要更灵活订购选项的用例可以继续使用基于偏移量的分页。如果用例需要具有较大偏移量的灵活排序选项，则建议对客户端进行排序。

删除代码片段内容搜索

更改日期：2020年5月22日

随着继续为代码段进行版本控制，将进行更改以在UI和API中搜索代码段，从而从搜索结果中删除代码段内容。标题和说明内容可通过搜索和API访问。

默认的应用服务器使用Puma

更改日期：2020年5月22日

GitLab将在13.0中将默认应用程序服务器从Unicorn切换到Puma。Puma是多线程应用程序服务器，使GitLab可以将其内存消耗减少约40%。

作为GitLab 13.0升级的一部分，自定义Unicorn设置的用户将需要手动将这些设置迁移到Puma。也可以通过禁用Puma并重新启用Unicorn，直到在将来的版本中删除对Unicorn的支持之后，才能保留在Unicorn上。

弃用Redis 3

更改日期：2020年5月22日

在GitLab 12.7中，Redis版本已更新为Redis 5。Redis 3已过期，并且从GitLab 13.0开始将不再受支持。

14.0不再支持GitLab Pages磁盘源

更改日期：2020年5月22日

GitLab Pages基于API的新配置将在13.0中可用，并将替换磁盘源配置。仍然可以在明年之前使用旧配置，尽管我们建议尽快（而不是稍后）切换到基于API的配置，因为旧配置将不支持新功能。在许多情况下，GitLab页面将自动切换到基于API的配置，而无需执行任何操作。现在无需执行任何操作。从13.0开始，GitLab Pages将自动使用新的配置源，并在出现错误时回退到旧的配置源。还有一种方法可以强制执行旧的配置源，但是它将在14.0中删除。

Projects API中删除'marked_for_deletion_at'属性

弃用日期：2020年5月22日

对于使用GitLab Silver，Premium或更高版本的客户，GitLab在列出项目时的API响应当前返回一个名为的属性marked_for_deletion_at，该属性表示将项目标记为软删除的日期。为了使我们的API中的术语标准化，在GitLab 13.0中将不推荐使用此属性。marked_for_deletion_on已经添加了一个具有相同信息的新属性。

删除"projects"和" shared_projects"属性

弃用日期：2020年5月22日

为了提高性能，我们限制了`groups /：id端点返回的项目数量。从GitLab 12.9开始，我们将在组详细信息API上返回的项目数限制为100。

为了进一步改善此端点的性能，从GitLab 13.0开始，当通过API 请求组的详细信息时，我们将从响应中删除"项目"和"共享项目"属性。用户仍然可以在同一组API的列表中找到一个组的项目端点。

引入"id"字段，用来替换JSON通用安全性报告中的"cve"

更改日期：2020年5月22日

GitLab当前用于安全报告的JSON通用报告格式需要改进，特别是当我们鼓励并添加第三方安全供应商集成时。主字段cve属性令人困惑，因为它不包含CVE数据，因此应将其删除。将引入id字段，该字段是为GitLab扫描仪自动计算的，并且是第三方合作伙伴扫描仪必需的。该id字段最终将替换cve为唯一的发现标识符。任何cve使用安全性报告，自定义脚本或作为我们的安全功能的集成者利用该属性的人，最终将需要停止使用该cve属性，而应该开始使用新id属性。请注意，今天id和cve都是必填字段。

sidekiq-cluster将成为在GitLab 13.0中调用Sidekiq的默认方法

更改日期：2020年5月22日

在GitLab 13.0中，我们将弃用sidekiq-cluster用于启动多个Sidekiq进程的参数。在GitLab 13.0中，默认情况下将启用Sidekiq Cluster，而不是sidekiq-cluster如启动多个进程中所述手动启用和指定参数，并提供一组默认参数。如果已经启用了Sidekiq群集，则应该没有可见的更改。

计划删除Runner的details API中的" token"属性

弃用日期：2020年5月22日

在GitLab 13.0（2020年5月）中，token将从Runners API接口中删除该属性，该属性通过ID来获取runner的详细信息。可以在相关问题或通常的支持渠道中提供反馈。

搬迁日期： 2020年5月22日

Omnibus GitLab中不推荐使用"user"设置

更改日期：2020年5月22日

在consul[user]和repmgr[user]的设置被取消，将在GitLab 13.0去除。GitLab中的其他服务使用username而不是user。为了保持一致性，将从13.0开始使用consul[username]和repmgr[username]设置提供Consul和repmgr的用户名。

升级更新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

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