GitLab 12.5发布，带来EKS集成、Crossplane多云托管和环境面板等

本周按照惯例Gitlab发布了新的月度版本12.5新版本。为了尽可能高效地交付高质量的软件，企业需要跨多个云支持广泛的基础架构，新版中对带来了EKS集群和环境面板让跨各种配置的项目配置，监视和管理变得更加容易。更多功能请随虫虫一起学习。

主要功能

EKS集成

Kubernetes是绝对复杂的，从头开始构建集群不是一件容易的事。尽管可以通过一些商业的云厂商产品来降低这种门槛，比如可以使用AWS的Elastic Kubernetes服务（EKS）之类的托管服务来抽象一些复杂性，也要遵循许多步骤才能开始使用。繁琐的手动步骤会分散我们的主要目标，使代码无法实时运行。在GitLab 12.5中，新添加了对EKS集成。可以在GitLab集群页面中选择EKS作为选项，然后将提示进行身份验证以使用AWS账户。一旦通过身份验证，只需为集群指定所需的参数，GitLab将负责完成其余的工作。

EKS集成不仅对让用户轻松地在AWS上部署到Kubernetes至关重要，也是多云策略的一部分。GitLab的GKE集成旨在使Kubernetes的安装更加容易，而且使多云更加容易。GKE集成只是一个开始。更大愿景是可以从各种云厂商中可自由选择，我们可以利用每个提供程序提供的独特优势并获得可移植性，以将应用程序和工作负载移动到所选择的云中，并同GitLab保持相同的一致工作流。

该功能位于功能标记的后面，要在自建实例中手动启用，启动方法：

使用gitlab-rails console启动Rails控制台，并运行：

Feature.enable(:create_eks_clusters)

使用Crossplane设置多云托管服务

Kubernetes应用程序现在可以与GitLab在一起部署，但是必须单独配置，连接和保护云服务依赖项。在GitLab 12.5中，可以使用开源的Crossplane项目以声明方式提供云服务，该项目扩展了Kubernetes API以提供托管服务，包括PostgreSQL，MySQL，Redis和对象存储。

Crossplane现在可以作为GitLab托管应用程序使用，可以安装到由GitLab管理的Kubernetes集群中。可以在标准的GitLab管道中或通过Auto DevOps使用kubectl声明性地设置和使用GCP，AWS和Azure的托管服务。

通过配置Auto DevOps以使用Crossplane，用户可以在集群外配置数据库，从而提供可用于生产的设置。

环境面板（PREMIUM及以上）

面临频繁的生产环境应用程序更改，在变更流程中各种开发，暂存和生产环境时，对环境变化跟踪是个问题。GitLab为此新增加了环境仪表板可显示该信息，从而提供对所有组和项目中环境状态的单点访问。这样我们可以快速，直观地识别并分类问题。

GitLab环境是一种逻辑结构，对代码所处的物理环境的状态和运行状况的管理使GitLab成为真正的CD解决方案的功能之一，而不仅仅是协调部署的CI工具。

新的环境面板提供了一个基于跨项目的基于环境的视图，可以用来大致了解每个环境中发生的事情。可以从一个面板跟踪从开发到临时验证，再到生产（或通过设置的任何一系列自定义环境流）全程变更进度。在一个视图了解多个项目，可以立即查看哪些管道是绿色的，哪些管道是红色的，从而可以一眼确定在哪些步骤存在问题，或者用来研究更多系统性问题。通过环境仪表板，可以使用这些附加工作流程来提高效率。

通过Sourcegraph支持代码智能

在开发时，开发人员依靠定位定义和查找，但是这在审查代码时并不可用。为此gitlab新版本对此做了增强，可以在浏览代码或查看合并请求时使用Sourcegraph的强大代码导航。

在GitLab 12.5中，当管理员配置了Sourcegraph集成后，便可以在用户首选项中选择使用。

将里程碑与发布关联

许多团队使用GitLab的方式是要为所有内容所跟踪的发行建立一个里程碑。有些团队可能还有一个以上的冲刺构成一个发布。新版本中可以将一个或者多个里程碑与发行版相关联。这样可以在发布页面中完成问题并合并版本发布所包含的请求。

更多功能介绍

组的审计事件API

审计事件API提供对GitLab环境的关键见解。之前该API仅管理员可用。先版本中已通过GitLab API访问了组活动数据，判断并并管理组的合规性。审计事件今后将会增强，使其更加全面，从而为提供更多见识和价值。

组、子组和项目概述的上下文导航

当开始通过其他组，子组和项目来组织组织时，很难确定所在层次结构中的位置。新版本中改进了左侧导航窗格中的上下文概述项，因此可以快速确定查看的项目，组还是子组。

设计注释添加到问题活动（PREMIUM及以上）

截止为止，当添加新的设计注释/注释时，注释仅在设计中列出。在新版本中当添加新的注释时，GitLab还将在讨论选项卡上的问题活动中添加注释，以便所有参与该问题的人都知道。这使得在设计讨论中进行协作变得更加容易，因此每个人都可以为设计过程做出贡献。

缓存Git信息/参考（Bata）

当获取对Git存储库的更改时，Git服务器会发布存储库中所有分支和标签的列表。在某些情况下，观察到对GitLab Web服务器的所有请求中，多达75%是对引用的请求。在最好的情况下，当所有参考文件都打包时，这是一个相对便宜的操作。但是，当有解压缩的引用时，Git必须遍历解压缩的引用。这会导致额外的磁盘IO，并且可能很昂贵，尤其是在使用诸如NFS的高延迟存储时。

在GitLab 12.5中，实例管理员可以手动启用信息/引用缓存以提高引用的性能，并减少引用非常频繁获取的情况下对Gitaly的压力。

根据GitLab线上托管平台的功能测试表明，当读取操作数量多于进行10到1的写操作，中值等待时间减少了70%。对于使用NFS进行Git存储的GitLab实例，期望会有更大的改进。

默认情况下不启用缓存，因为这会导致缓存上的写入压力高于预期，这可能是由于并行缓存未命中造成的。

合并请求API中添加了可合并性状态

合并请求API现在包含有关合并请求为何无法合并的更多详细信息。 has_conflicts属性表示是否存在合并冲突，blocking_discussions_resolved属性表示是否存在未解决的讨论。这些新属性对于自动化（确定合并请求可合并所需的操作）特别有用。

将查询字符串中的值传递到"pipelines/new"页面

要通过Web创建新管道，请转到/pipelines/new，然后可以在其中为要启动的管道填写不同的值。已经可以添加ref参数来选择分支或标记（例如/ pipelines / new?ref=master），新版本中还添加了类似功能，可以在查询字符串中预设置其他变量。

gitlab-ci.yml中的可组合脚本别名

创建可重用的元构建基块是管道设计的强大范例。可以让项目保持DRY状态，将功能划分为可以理解的块，并创建依赖链，以便一次更新代码块可以同时为许多依赖块更新。

GitLab有几种机制可以启用此设计模式，包括默认的YAML语法，例如锚和别名。但是，但是当别名为script，before_script或after_script关键字时候，则在尝试合并它们时会导致数组嵌套导致异常。

在GitLab 12.5中，通过对script锚点引用时会解包。如果想通过包含和扩展使用此模式，则无法使用，但是可以在单个文件中使用锚来解锁一系列强大的新管道设计模式。

在合并请求中显示JUnit错误详细信息

在此版本之前，用户可以看到测试何时失败，但无法获得解决失败所需的数据。在新版本中，GitLab现在在管道视图中显示有关JUnit测试结果的数据。包括通过，跳过和失败的测试结果以及时间安排，以及单个测试的详细视图，包括失败测试的信息，以便更快地识别问题和解决问题。

帮助用户下载NPM软件包（PREMIUM及以上）

根据用户调查用户导航到Package Registry UI的主要原因是确保他们使用的是正确版本的软件包。

在GitLab 12.5中，改进了GitLab Package Registry的导航和工作流程，用户可以轻松复制npm install和npm setup片段，以轻松安装所需的软件包。

功能标记的公共API（PREMIUM及以上）

新版本中添加了API功能，该功能将允许配置和管理功能标志。以前只能通过UI进行此操作。

基于CI的集群应用程序管理

一键安装Kubernetes应用程序对于快速启动和运行非常有用。但是，有时需要在安装之前自定义Helm chart。新的基于CI的群集应用程序管理方法将允许用户指定"群集管理项目"，该项目将获得对群集的群集管理特权，并能够通过CI与群集进行交互。这不仅将允许安装模板化的应用程序，而且还允许用户在安装之前自定义图表。此外，在管理Kubernetes应用程序时，用户将能够使用围绕安全性，身份验证，版本控制和CI的所有现有GitLab功能。

GitLab Serverless中的OpenFaas运行时支持

GitLab Serverless现在支持Open FaaS经典运行时。使用OpenFaas运行时，开发人员可以使用6种支持的语言中的任何一种为Knative编写无服务器功能。

使用Prometheus的恢复警报自动关闭问题（ULTIMATE）

解决之后，出于跟踪目的，需要关闭事件问题，以便不会混淆哪些事件正在发生以及哪些事件仍需要修复。当由于某人已解决问题而解决警报时，Prometheus将发出恢复警报，使GitLab能够自动关闭与事件相关的问题。这消除了事件响应者不必要的手动工作，并确保每个未解决的事件都是一个积极的问题，需要引起注意。

按标题过滤Sentry错误列表

分类错误需要能够根据自定义和特定于您的用例的条件对列表进行过滤和排序。新版本中可以在与Sentry集成的GitLab项目中搜索Sentry错误列表。只需使用左侧的栏导航至操作>错误跟踪，即可在GitLab中查看Sentry错误并进行搜索。

Slack Slash命令添加要发布的注释

ChatOps就是通过直观的命令和操作来启用操作，这些命令和操作可以键入并集成到聊天工具中。新版本中扩展了现有的Slack斜杠命令套件，该命令允许在不退出Slack的情况下为GitLab问题添加评论。这减少了上下文切换，并消除了仅导航多个UI来更新问题的队友或利益相关者的麻烦。

编辑指标面板

此前，为了定义自定义仪表板，用户必须在存储库的根目录下创建一个YAML文件，并从头开始填写其内容。这有点难以实现，需要手动操作。

在GitLab 12.5中，可通过单击"编辑仪表板"按钮，将被重定向到Web IDE，在此可以更新修改预设的YAML文件。

适用于React框架的SAST（ULTIMATE）

新版本扩展了SAST Javascript扫描，以支持特定于React的文件和项目。

这可以帮助识别和修复React应用程序中的潜在漏洞。

Web应用程序防火墙的阻止模式（ULTIMATE）

新版本中将Web应用程序防火墙（WAF）置于阻止模式。只要WAF识别出潜在的恶意流量，就会将其丢弃，从而保护其免受各种不同的攻击。

可以通过在项目中设置AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE环境变量来启用此行为。如果未设置此变量，则WAF将在仅日志记录模式下运行。

脱机容器扫描（ULTIMATE）

对于自建GitLab实例，新版本中可以在脱机（空白）安装中启用容器扫描。这样就可以进行容器扫描，而无需访问Web。

Docker-in-Docker依赖性不再是依赖性扫描的要求（ULTIMATE）

以前，依赖关系扫描利用了Docker-in-Docker配置。通过删除Docker-In-Docker要求，新版中不需要使用特权运行器，并且运行器现在可以缓存映像。消除对特权运行者的需求，可以更轻松地更安全地使用依赖关系扫描。

增强了Geo更新的弹性（PREMIUM及以上）

为了简化Geo升级过程，新版本修复了Geo更新过程中更新外部数据包装器（FDW）表时的一些小问题，并更新了相应的文档。这样系统管理员所需的人工干预更少，这将增加Geo更新的整体健壮性。

有关使用Geo升级多节点/ HA部署的说明（PREMIUM及以上）

作为简化Geo升级过程的一部分，新增加了Geo多节点/高可用性部署的零停机升级说明。

这些说明对于维护许多用户的大型GitLab安装的GitLab客户特别有价值，因为它们消除了额外的停机时间。

检查Geo节点仅显示特定于节点的输出（PREMIUM及以上）

在Geo主节点上运行gitlab-rake gitlab:geo:check时，展示了许多仅与辅助节点相关的信息。

在GitLab 12.5中清理了gitlab:geo:check输出，仅运行与运行命令的节点类型（主要或次要）相关的检查。

在云原生安装中支持Geo（PREMIUM及以上）

将代码托管在的开发人员物理邻近的位置，可以减小大型仓库上的git clone的停顿时间。GitLab Geo提供了git仓库的地理复制，因此可以让开发人员在整个城市或全球范围内进行协作。以前，Geo仅适用于Omnibus GitLab，而使用Kubernetes的人们则只能喝很多咖啡等待。因此，对GitLab chart的地理支持已成为人们高度要求的功能。

从12.5开始，GitLab Helm chart支持配置主要和辅助Geo实例。

更新以警告横幅样式

根据设计系统中的新规范，新版本中应用程序中更新了Alert组件。这些新样式使警报banner文本易于阅读，特别是在banner中包含链接的情况下。

使用ping中的额外项目服务计数

为了更好地了解用户最常使用哪些集成，已将使用"自定义问题跟踪器"，Jira，Jenkins，Slack和Mattermost项目服务的项目数量添加到使用ping有效负载中。随着有效负载添加其他项目服务，该工作将在接下来的几个版本中继续进行。

关于GitLab Ping服务可以参考相关的官方语法。

GitLab Chart改进

GitLab 12.5中，添加了对在GitLab Helm图表中配置外部Redis Sentinel服务器的支持。现在，可以提供Redis HA集群中Sentinel服务器的主机名，端口和密码的列表，作为全局设置。请注意，仅与GitLabChart分开部署的Sentinel服务器才支持此配置。

组里程碑改善

在GitLab 12.5之前，如果将一个项目里程碑提升为组，则会丢失许多项目里程碑提供的有意义的元数据。现在，组里程碑与项目里程碑是同等的，并且包括问题概述，合并请求，参与者以及与该里程碑相关的标签。

AsciiDoc的颜色块

AsciiDoc文件现在支持彩色块。在支持AsciiDoc地方，比如Wiki，摘要和存储库文件预览中，输入的颜色代码都将在其旁边呈现一个有用的颜色块。当设计师和工程师在GitLab中就颜色细节进行协作时，这特别有用。

合并后删除源分支

很容易忘记从已合并的合并请求中删除分支，从而导致分支数量迅速增加。在GitLab 12.5中，默认情况下会删除功能分支以保持的项目整洁。

可以手动设置关闭该功能。在项目设置中添加了一个新的切换开关，以禁用"删除源"分支选项。

使用稀疏签出快速rebase

快进和半线性合并方法要求目标分支中没有源分支中没有的更改。当目标分支中的更改不在源分支中时，将显示"Rebase"按钮以使合并请求保持最新状态。

当Git执行rebase时，将使用工作树来完成操作。在GitLab 12.5中，在创建工作树时会使用稀疏签出，这样用于执行变基的工作树不包括存储库的完整工作副本，而仅包含几个文件。

作业日志默认扩展

默认情况下，将扩展作业日志部分，以使日志视图更易于浏览，从而使您可以更快地找到失败的作业所需的内容。

在合并请求视图中显示自定义构建结果

构建过程可能会生成工件，例如测试结果，代码指标和统计信息，用户希望以视觉表示的方式看到这些工件，但是这些项目在MR中尚不可用。以前，要访问构建工件，需要导航到工件浏览器并离开MR的上下文。

在GitLab 12.5中已将自定义工件引入MR小部件的管道部分。使用gitlab-ci.yml中的Exposure_as关键字，现在可以在MR小部件中直接显示工件。

提交SHA现在可以用作缓存键

GitLab CI/CD允许指定应在作业之间缓存的文件和目录的列表。从缓存中拉出文件而不是从sratch构建文件是加快管道速度的好方法。但是，如果文件有新版本且缓存未更新，则缓存会很糟糕。在GitLab 12.5中，通过使用提交的SHA作为缓存键的新功能，缓存管理变得更加容易。由于这与生成文件的基础来源相对应，因此这是一种确保缓存过期随实际更改而变的自然方法。这将使管道中的缓存更易于设置并且效率更高。

使用CI/CD更新GitLab NPM注册表（PREMIUM及以上）

在GitLab 12.5中，用户可以利用GitLab CI/CD来构建软件包并将其推送到项目或小组的NPM注册中心。未来，用户现在可以利用从.gitlab-ci.yml调用的作业令牌CI_JOB_TOKEN进行身份验证并更新其NPM注册表。

改进了GitLab容器注册表的可用性

在GitLab 12.5中，发布了GitLab容器注册表的更新版本修复了不支持MD5校验的问题版本显著提高了功能的可用性。

单独部署GitLab Pages指南

可能需要在单独的服务器上运行GitLab Pages守护程序，以减少主应用程序服务器上的负载。新版增加了该部署的指南来帮助完成此任务。

在本地构建无服务器功能测试

了在本地运行测试，开发人员现在可以使用gitlabktl命令行工具构建其无服务器功能。命令行工具gitlabktl已扩展为支持使用Kaniko或Docker Engine的本地构建。

JavaScript开发人员的新项目模板

借助新的面向JavaScript的项目模板，可以开始使用GitLab Pages和AWS Lambda快速构建和发布项目。开始使用喜欢的框架对前端进行编码，让Serverless和AWS Lambda满足后端需求，并使用Gi​​tLab页面以1分钟的设置来托管您的解决方案。

使用Grafana URL在GitLab问题中渲染图表

当团队对问题进行分类和解决时，指标图表可让我们了解服务/系统的哪些部分受到影响以及影响了那些用户，并将此信息发送给有关人员。但是，使用复制和粘贴将屏幕快照从Grafana手动移至GitLab问题时很容易出错，还影响速度。

在GitLab 12.5中，增加了通过GitLab图表在问题中呈现Grafana指标的功能，只需在问题描述中包括Grafana图表的URL。可以手动添加，也可以通过将URL添加到问题模板来自动呈现在问题中。

在GitLab中查看重要的Sentry错误细节

上下文切换使每个人的速度变慢。不同工具的独特UI和交互模式使日常分类任务变得繁琐。为了克服这些挑战，Sentry的集成中新增加了从GitLab中查看错误详细信息的功能。

这使可以查看错误的相关方面，例如首次/最后一次看到，事件数，受影响的用户数以及GitLab中的堆栈跟踪，而无需切换到Sentry。当然，如果需要更深入地了解，需要通过点击链接到Sentry的错误记录。

指标面板的异常图表

在可视化指标时，用户通常喜欢为不同的指标选择不同的可视化类型，并设置上限和下限以更好地发现图表中的异常。

为了帮助实现这一目标，新版本中添加了异常图表，以此来增强围绕监控的仪表板产品。

Omnibus的改进

GitLab 12.5中，Mattermost更新到了5.16，它是开源的Slack替代产品，其最新版本包括新的Plugin Marketplace，在桌面上的更快安装等。此版本的Mattermost删除了对IE 11的支持。 GitLab现在包括一个新的Mattermost插件，该插件可将GitLab通知和slash命令到Mattermost。

升级Omnibus GitLab时，/etc/gitlab现在会自动备份。这样可以确保GitLab配置数据包含在升级前的备份中。如果升级期间由于某种原因备份配置数据失败，会发出警告，但升级将继续。

GitLab高可用性使用Consul管理PosgreSQL数据库节点的服务发现，运行状况检查和故障转移。在12.5中，Omnibus内置的Consul版本已从0.9.0更新到1.6.1。

默认情况下在Omnibus中启用了GitLab容器注册表。通过确保可以在构建阶段将容器上传到容器注册表，而无需进行配置更改，这为构建和使用容器提供了一条更快捷的途径。

GitLab Runner 12.5

GitLab还同期发布了GitLab Runner 12.5。改进包括：

Document GitLab的Docker Machine fork；

提供DOCKER_MACHINE_VERSION；

升级到Alpine Linux 3.10；

针对K3/容器的修复；

更改锁定配置以创建单独的锁定文件

修复Linux卷的绑定；

可能尚未保留在磁盘上的计算机计算机列表；

在配置中为Kubernetes执行程序添加服务定义；

详情可以查看GitLab Runner的CHANGELOG。

性能改善

GitLab 12.5中提供的一些性能改进包括：

将IP列入白名单时，跳过Redis请求；

从头像请求中删除不必要的SQL查询；

SQL语句在确定要同步的Ci::JobArtifact记录时超时设置；

使用批处理加载器加载GraphQL中的重大问题；

以及文本前面提到的一些缓存功能的改善。

功能弃用

在GitLab 12.6中将删除对Knative版本0.5的支持

随着对Knative 1.0的支持，在GitLab 12.6中将放弃对Knative 0.5的支持。

去除日期：2019年11月22日

不再对openSUSE Leap 15.0支持

openSUSE 15.0将于2019年11月结束生命周期。在GitLab 12.5中将不再支持openSUSE 15.0。 openSUSE Leap 15.1的软件包现在可用。

变更日期：GitLab 12.5

GitLab 13.0将弃用PostgreSQL 9.6和10.x

为了利用PostgreSQL 11中改进的性能和功能（例如分区），计划在GitLab 13.x中仅支持PostgreSQL 11和12版本。

通过最低要求PostgreSQL 11，能够利用引入的新功能，而无需维护多个代码路径的开销。未来将保持每年一次的PostgreSQL升级节奏，并在支持第二和第三最新版本后立即对其进行支持。

变更日期：GitLab 13.0

通过API请求组详细信息时限制返回的项目

当通过GET或PUT请求返回组的详细信息时，GitLab的API响应先前会返回组项目的完整列表，有时会导致大量的Gitaly调用。在GitLab 12.6中，计划将返回的项目数限制为100，以提高服务这些请求时的性能。

生效日期：2019年12月22日

不再支持Elasticsearch 5.6

随着持续改进和增强与Elasticsearch的集成，GitLab 12.7的发布将结束对Elasticsearch 5.6.x的支持。随着Elasticsearch 7.x的发布，Elasticsearch 5.6达到了使用寿命。 GitLab 12.7的更新版本不再对Elasticsearch 6.x的提供支持。

变更日期：2020年1月22日

升级更新

Omnibus封装自建的GitLab实例，可以使用发行版的包管理器一键升级。

CentOS下可以直接通过下面的命令：

yum updata/install gitlab-ce

有关升级到GitLab 12.5的重要说明

Omnibus GitLab中的Consul版本从GitLab 12.5中的0.9.0更新为1.6.1。在高可用性群集中升级Consul节点时，必须一次升级Consul节点一个节点。捆绑的Consul的升级中记录了升级过程。