GitLab 13.7，增加MR审阅者，部署失败时自动回滚等功能

12月22日距离平安夜还有两天，距离新年还有一周多点，又到Gitlab发版的日子了。这次发布的版本是Gitlab 13.7，虽然和日常的功能略少点，但是也包括了45项功能和改进，详细的功能请和虫虫一道学习尝试。

概述

增强项目管理以实现跨协作

合并请求（MR，Github中是PR）是Git生态协作交互中最重要的部分。它促进了Fork协作，支持将其与相关问题直接关联，提供一个中心位置，通过commit进行交流，代码更改建议，执行代码审查等。在新版本中，Gitlab添加了合并请求审阅者，功能通过使审阅更加容易和更有条理来改善代码审阅过程，新功能可以快速找出合并请求中涉及的人员，或请求进行正式审查向他们发送通知。

工作流中的上下文切换和手动任务阻碍了在组和项目之间进行有效协作的能力。花费更少的时间来开发有价值的功能，而花费更多的时间来管理项目，这就是为什么能够快速采取行动克隆问题的对简化敏捷规划和项目管理如此重要的原因。

在项目上进行协作并快速迭代以开发应用程序，这样需要能够快速确定问题的重要性顺序，确定所有阻止者，并使用该信息确定下一步的工作重点。现在，新版中可以按阻止者对问题进行排序，以快速找出哪些问题阻止了其他问题的进展，以及轻松按问题列表中阻止者的数量进行排序。

改进的发布自动化和部署灵活性

用户需要灵活性来控制如何定期组织，自动化和部署应用程序。可靠且频繁地部署应用程序可以更快地将价值带到客户手中。

为了改善GitLab自动发布的方式，新添加了在发生故障时自动回滚的功能。此功能会自动将失败的部署恢复为上一次成功的部署，并发送自动通知以提醒用户当前状态。无需手动进行任何更改，并且可以确信在尝试解决问题时，潜在的问题不会导致停机或加剧。

发生故障时自动回滚非常适合进行一项改进，即能够在“环境”页面中查看部署状态。现在，可以轻松找到部署状态并确定需要执行的操作，例如停止或回滚部署。

更可靠，高效的软件包和依赖项管理

用户的工作流程取决于多种编程语言，二进制文件，集成和工件，这些都是开发过程的重要输入或输出。为了可以更有效地管理软件包和依赖项，从而减少浪费的开发时间，并且出于效率考虑，新添加了快速查找和查看通用软件包的选项。还对GitLab的依赖项代理进行了改进，已经在GitLab 13.6的Core中提供。

现在，可以避免Docker速率限制，并使用Dependency Proxy来加快管道的速度，以确保在缓存DockerHub上托管的容器镜像时对可靠性的信心并提高效率。

社区中许多人都希望看到的另一个改进是，Dependency Proxy现在可以与私有项目一起使用，并解决了那些使私有项目的人无法利用此功能的限制。

最后但并非最不重要的一点是，支持预定义变量与依赖项代理一起使用，而不必依赖于自己定义的变量或gitlab.ci-yml文件中的硬编码值。这提供了一种更可扩展且更有效的方式来开始代理和缓存镜像。

GitLab 13.7主要功能

合并请求的审阅者

要求小伙伴们帮你代码应该开发的日常工作，但这通常很繁琐。要求进行审查之类的简单任务可能会导致混乱。例如，应该怎么开始？一封邮件？评论？聊天消息？没有正式的流程，评论可能会不一致并且难以跟踪。此前，一种选择通过合并请求中分配审阅者。即使具有这种形式，作者和审阅者都出现在参与者中，这使得其他团队成员很难知道谁在做什么。

GitLab 13.7引入了用于合并请求的审阅者，允许作者向某发出请求审阅。新的“审阅者”字段允许以与参与者相似的方式将用户指定为审阅者。审阅者收到通知，邀请他们审阅合并请求。这提供了一个请求审阅的正式流程，并阐明了合并请求中每个用户的角色。

未来的迭代将包括显示合并请求中最相关的审阅者，以及使审阅者成为中心的简化的合并请求批准流程。

发生故障时自动回滚（ULTIMATE）

如果部署中遇到严重问题，则通常需要花费很长时间来进行手动操作以解决该问题，并且会导致影响用户的生产质量下降。现在，可以利用自动回滚机制，将部署还原为上一次成功的部署。此外，当GitLab在生产中发现问题时，它会自动以发出告警通知。这使高枕无忧，并有宝贵的开发时间来调试，研究和解决问题，而不会造成停机。

快速克隆问题

为了使生成类似问题的效率更高，问题现在支持/clone快速行动，该行动可以在同一项目中创建具有相同标题，描述和元数据的新问题。该/clone行动迅速取代了较为繁琐的过程，它涉及多个步骤来创建一个问题，复制源问题的ID或路径，并使用copy_meta快速行动。

默认情况下，问题被克隆到同一项目中，并不包括评论，但是也可以在克隆时更改默认行为。

Red Hat OpenShift GitLab Runner镜像

今天可用的是Red Hat OpenShift容器平台的GitLab Runner容器镜像。要在OpenShift上安装运行程序，可以使用新的GitLab Runner操作程序，该程序可从Red Hat的Operator Hub的beta通道中获得。该Operators是一个Web控制台，OpenShift群集管理员可以发现并选择要在其群集上安装的Operators。默认情况下，Operator Hub部署在OpenShift容器平台中。预计在2021年初将GitLab Runner Operators在稳定版发布，并向GA进行过渡扩展。

在“环境”页面上显示部署状态

以前，在查看“环境”页面时，无法知道正在进行部署。通过现在可以看到部署状态和警报，“环境”页面将指示可以根据部署状态（成功，失败或进行中）采取何种操作。例如，可能想停止当前正在进行的部署，或回滚完成的部署。

通过UI设置部署流量权重（PREMIUM及以上）

在GitLab 13.7中，可以直接从用户界面中的部署板更改canary权重。可以直接从gitlab-ci.ymlAPI和API中更改canary的权重，但是在UI中，可以查看部署并直接从Deploy Boards缩放Pod。这样可以更好地控制手动或定时增量部署，并可以更好地缓解风险。

API支持部署频率（ULTIMATE）

作为首次在GitLab中支持DORA4指标的迭代的一部分，此版本增加了对项目级别部署频率的API支持。这样，可以随着时间的推移监视部署的效率，轻松找到瓶颈，并在必要时快速采取纠正措施。

在一个项目中支持多个清单文件（PREMIUM及以上）

在以前的GitLab版本中，GitLab Kubernetes代理要求用户将所有Kubernetes资源收集到一个清单文件中。在新版本的GitLab中，GitLab Kubernetes代理可以从项目中的指定目录中递归地获取Kubernetes清单。平台工程师可以使用一个存储库从一个地方管理不同的集群，并且可以使用一个代理描述大型部署。

需求导入（ULTIMATE）

将所有需求放在一个地方对于高效协作至关重要，新版本中在可以从CSV（逗号分隔值）文件中导入需求。

此功能将使整个团队可以根据GitLab的要求进行协作，但仍可以使轻松地与客户，供应商和外部组织进行交互。

告警工具与多个HTTP接口集成（PREMIUM及以上）

告警集成是事件管理工作流程中的关键部分，这就是为什么用户和团队具有对终结点和身份验证令牌的精细控制非常重要的原因。用户想要做的就是通过重置单个身份验证令牌来消除所有告警。为每个监视工具设置一个HTTP接口，使团队可以分别管理每个工具，而不会影响其他工具的告警。

DevOps的使用报告（ULTIMATE）

DevOps Adoption显示组织中的哪些团队正在使用GitLab问题，合并请求，批准，运行程序，管道，部署和扫描。使用新的细分功能将GitLab组分组为对组织有意义的逻辑业务部门，以便可以轻松比较不同组之间的GitLab采用情况。

验证用户是否从GitLab获得了预期的投资回报。

确定在采用GitLab方面滞后的特定人群，以便可以在他们的DevOps旅程中提供帮助。

确定采用了特定功能（例如管道）的小组，并可以向有兴趣使用这些功能的其他小组提供提示。

改进了用于项目创建的UI

改进的用于添加项目的用户界面使用户可以更轻松地选择创建空白项目，从模板启动项目，导入现有项目以及为外部存储库创建仅CI/CD的项目。

选择直接从合并请求中一次显示一个文件

合并请求审阅是确保贡献者提供高质量代码的一项重要任务，因为这是作者与审阅者之间大部分沟通的地方。但是，随着合并请求变得更大并且涉及更多文件，合并请求差异的导航和性能可能会变得困难。

GitLab 13.7引入了在合并请求视图中一次显示一个文件的选项。导航到合并请求的“更改”标签时，点击齿轮图标并选中一次显示一个文件框。这将一次显示一个文件，并使“上一个”和“下一个”按钮在文件之间导航。

单个文件模式提供了更整洁的工作空间，并增强了审阅者对单个文件的关注，同时提高了合并请求差异的性能和导航。

查看VS Code中的合并请求更改

在VS Code中检查合并请求时，轻松引用更改通常需要签出分支，然后尝试确定该分支与合并目标之间的差异。

在GitLab Workflow 3.7.0版本中，合并请求更改可直接在VS Code中获得。这样可以快速查看项目中合并请求的更改。

通过子管道改进工件下载

以前，将工件从父管道下载到子管道并不总是提供所需的工件。如果两个父管道同时运行，则子管道可能会意外地从较新的管道下载工件。

现在，可以使用新needs:pipeline语法来告诉子管道确切的管道，以从中下载工件。可以使用它从父管道或同一父子管道层次结构中的其他子管道下载工件。

避免Docker速率限制并加速管道

为了更快，更可靠的构建，可以使用依赖代理来缓存Docker Hub上托管的容器镜像。但是，当Docker开始对来自Docker Hub的拉取请求实施速率限制时，会注意到，即使从缓存中拉出镜像，Docker也会将其计入限制。这是因为“依赖代理”仅缓存镜像层（或Blob），而不缓存清单，清单包含有关如何构建给定图像的信息。由于清单是必需的，因此仍然需要拉取请求。这样，如果Docker Hub不可用，则无法拉出镜像。

向前，依赖代理将缓存镜像的层和清单。因此，第一次拉取alpine:latest，该镜像将被添加到Dependency Proxy缓存中，并且算作一次对速率限制的拉取。下次拉取时alpine:latest，即使Docker Hub不可用，也将从缓存中拉出，并且不会计算速率限制。

快速查找和查看通用软件包

可以使用GitLab软件包注册表轻松发布通用文件，例如发行版二进制文件。但是，如果您使用Packages UI和其他软件包管理器格式，则可能会注意到无法选择一个选项卡来仅快速查看常规软件包。

最近在Packages UI中添加了一个名为Generic的标签，因此可以将视图限制为仅适用于通用软件包。希望这可以帮助用户更快，更有效地查找和验证软件包。

对私有项目使用依赖代理

可以使用GitLab依赖关系代理从Docker Hub代理和缓存容器镜像。直到最近，该功能仅适用于公共项目，使许多人无法使用它。

现在，可以将依赖项代理与私有项目一起使用。可以通过缓存容器镜像以备将来使用，从而减少对Docker Hub的依赖。由于Dependency Proxy将Docker镜像存储在与组关联的空间中，因此必须使用GitLab用户名和密码或使用范围至少设置为的个人访问令牌进行身份验证read_registry。

在外部文件中定义发布说明

如果通过项目的.gitlab-ci.yml文件在管道中创建发行版，则可能发现很难维护每个发行版的描述。在GitLab 13.7中，现在可以在源代码控制或自动生成的文件中定义发行说明，并从中调用.gitlab-ci.yml。这样做会将文件内容作为Markdown加载到发布说明中。版本发行更易于创建，维护和与版本控制一起使用，如果要自动生成变更日志，则特别有用。

添加对Kubernetes版本1.17、1.18、1.19的支持

GitLab对最新Kubernetes版本的支持使可以从GitLab的Kubernetes集成中受益，例如GitLab Kubernetes代理，Auto DevOps，以及在较新的集群上托管应用程序。GitLab增加了对Kubernetes版本1.17、1.18和1.19的官方支持。

Geo支持复制版本控制片段（PREMIUM及以上）

Geo现在支持将Versioned Snippets复制到辅助节点，允许分布式团队从最近的Geo节点访问它们，从而减少了延迟并改善了整体用户体验。此外，在故障转移到该辅助节点时，还可以从辅助节点还原该数据。

成员MVC的组Webhooks（STARTER及以上）

GitLab使您更容易使用一个Webhook构建用户管理自动化，该Webhook是在将新成员添加到组中时触发的。以前，必须运行REST调用来标识新的组成员，这会给GitLab实例带来不必要的性能负载。

改进的组成员列表过滤和排序

通过新的过滤和排序体验来改进组成员列表，使组管理员可以快速找到其需要的成员信息。例如，按“上次登录”排序可用于查找最近未访问过GitLab的用户并协助许可管理活动。

在Service Desk中使用自定义电子邮件地址

GitLab服务台的电子邮件地址很难记住，因此用户难以使用。通过引入可配置的电子邮件地址，现在可以选择对企业标识有意义的地址后缀，并使用户更容易记住。这是GitLab采取的又一个步骤，为用户提供最优质的支持。

区分格式更改和通过静态网站编辑器进行的编辑

静态站点编辑器为Markdown内容提供了直观，熟悉的所见即所得编辑模式。为了确保格式一致的Markdown输出，WYSIWYG编辑器会自动重新设置页面内容的格式，以匹配Markdown解析器中定义的样式约定。这甚至在开始编辑之前就完全在后台发生。但是，这些格式更改是在内容编辑的同时提交的。如果正在编辑的页面没有遵循相同的样式约定，则结果合并请求的审阅者可能很难区分手动更改和自动格式设置。

从GitLab 13.7开始，静态站点编辑器将自动修复Markdown语法中的不一致之处，并将所有必要的格式更改提交到新分支。完成编辑后，“发布”按钮将创建一个单独的提交，其中只包含用户更改。这可以为审阅者节省时间，使他们不必专注于语法更改，而可以专注于内容。

手动运行管道时的预填充变量

以前，当需要手动运行管道时，需要了解相关变量，然后在“运行管道”页面上输入它们。如果要输入许多键值对，这可能会很乏味且容易出错。现在，“运行管道”表单将根据.gitlab-ci.yml文件中的变量定义为管道生成预填充的变量，从而使此过程更加高效。

使用CI/CD构建的软件包始终显示构建信息

如果一直在将软件包发布到Package Registry，则可能已经注意到，使用GitLab CI/CD构建的软件包并不总是显示负责创建或更新软件包的提交和管道。出于某些原因可能会发生这种情况。

首先，我们可能还不支持此功能，就像Composer和Conan一样。其次，对于那些已经从不同分支或提交更新同一版本的软件包的人来说，这是一个问题。可以从不同的分支和/或提交发布具有相同版本的软件包。直到最近，UI仍仅显示第一个部署，而未包含任何更新。此外，详细信息页面显示了创建软件包的分支，而不是最近的提交。结果，必须尝试通过查看提交历史记录来查找此信息，这不是很有效。

展望未来，使用GitLab CI/CD创建或更新的任何软件包都将在“软件包”用户界面中显示提交和管道信息。为避免性能或UX问题，将仅显示软件包的五个更新。在13.8中，将创建一个设计，以帮助直观地查看所有历史数据。同时，可以使用Packages API查看给定软件包的整个构建历史记录。

将预定义变量与依赖代理一起使用

通过从Docker Hub代理和缓存容器镜像，Dependency Proxy可以帮助提高管道的性能。即使打算将代理与CI/CD一起大量使用，但要使用该功能，也必须在文件中定义自己的变量或硬编码值gitlab.ci-yml。这使个人难以上手，并使其无法成为可伸缩的解决方案，尤其是对于具有许多不同组和项目的组织而言。

未来，可以使用预定义的环境变量作为使用依赖代理的直观方法。支持以下变量：

CI_DEPENDENCY_PROXY_USER：CI用户，用于登录到依赖代理。

CI_DEPENDENCY_PROXY_PASSWORD：用于登录依赖代理的CI密码。

CI_DEPENDENCY_PROXY_SERVER：用于登录依赖代理的服务器。

CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX：用于通过依赖代理获取镜像的镜像前缀。

查看在fork项目和父项目中运行哪些提交和管道

在GitLab 13.3中可以使用父项目的开发人员来创建派生项目中合并请求的管道。但是，没有办法知道管道运行的上下文。

在新版本中，现在可以查看在派生项目与父项目中运行了哪些提交和管道。分叉的提交具有唯一的徽章和工具提示，可让用户知道它们是从分叉的合并请求中运行的。这使用户很容易了解管道运行的上下文，从而无需更详细地调查起源。

PostgreSQL 12是新安装的默认设置

从GitLab 13.3开始，PostgreSQL 12已成为Omnibus软件包以及我们的Helm Chart的可选加入选项。PostgreSQL 12提供了显着的索引编制和分区优势，以及更广泛的性能改进。

在GitLab 13.7中，新安装的GitLab将从13.7开始默认为PostgreSQL 12。要手动升级，请运行gitlab-ctl pg-upgrade。

在使用Patroni进行升级之前，多节点数据库实例将需要从repmgr切换到Patroni。然后可以更新Geo辅助数据库并重新同步。

Gitlab Runner 13.7

今天同期还将发布了GitLab Runner 13.7。新增加的功能：

能够删除umask 0000使用GitLab Runner Docker执行程序执行的作业。

使用主机别名为Kubernetes支持额外的主机。

支持Kubernetes Pod DNS配置。

提高高速网络上的缓存上传速度。

添加对Windows Server 2004（半年发行版）的支持。

从Docker Hub中删除对Kubernetes初始化容器的依赖。

将GitLab Runner Docker镜像发布到Amazon Elastic Container Registry。

从FF_GITLAB_REGISTRY_HELPER_IMAGE功能标记后面的GitLab.com容器注册表而不是Docker Hub提取帮助程序镜像。

TSL协议要求最低版本为TLS 1.2。

basefolder创建VirtualBox VM时允许指定。

当GitLab Runner与systemd一起使用时删除重复的日志。

清除机密时出错：资源名称可能不为空。

当默认存档程序提取文件时，FastZip存档会有警告。

删除构建目录中的.git/onfig.lock。

GitLab Helm chart改进

由于更改了Webservice部署的管理方式，因此通过Helm Chart部署的GitLab实例将在此升级期间短暂中断。

现在，可以按路径划分GitLab Webservice Chart的不同部署之间的流量，从而可以划分工作负载。

nginx已更新为v0.41.2，是重大更新。由于上游Pod参数更改，当基础Pod重新启动时，可能会发生短暂中断。

registry已更新至2.12.0-gitlab，gitlab-kas至13.7.0，gitlab-runner图表至0.23.0，gitlab-exporter至7.1.2。

现在可以使用以下terminationGracePeriodSeconds命令配置NGINX的终止宽限期。

GitLab Praefect现在支持TLS加密。

Omnibus的改进

现在，ARM64软件包可用于CentOS 8。

LDAP凭证现在可以被加密。

Pages现在支持基于PROXYv2协议的HTTPS。

registry已经更新到2.12.0-gitlab，consul到1.6.6，grafana7.3.3，prometheus至2.22.2，并libjpeg-turbo到2.0.6。

GitLab 13.7包含Mattermost 5.29，它是开源的Slack替代品，其最新版本包括Mattermost Omnibus的一般可用性以及更多功能。还包括安全更新，建议从早期版本进行升级。

安全和合规性审计

限制预配置帐户的项目和组创建（PREMIUM及以上）

为了减少意外暴露知识产权的风险，GitLab管理员现在可以更好地控制由其小组的SAML或SCIM集成提供的帐户。在这些控件的第一次迭代中，管理员可以阻止其用户在尚不属于他们的组之外创建组或项目。

按问题阻止的数量对问题进行排序（STARTER及以上）

在GitLab中确定问题列表的优先级时，通常重要的是确定关键路径以及问题是否正在阻止其他问题。

使用当前的问题列表，无法查看哪些问题正在阻止其他问题。唯一的方法是打开每个阻止程序，然后在问题说明下方查看阻止程序列表，这是一项非常耗时的任务！

从13.7开始，可以使用过滤器对任何问题列表进行“阻止”，然后会看到一个按阻止者数量排序的列表。

改进了对SAST分析仪的多项目支持

GitLab安全扫描会自动检测代码语言并运行适当的分析器。使用monorepos，微服务和多项目的存储库，单个存储库中可以存在多个项目。以前，安全工具只能检测存储库中的单个项目。在此版本中，我们的SAST分析仪现在可以智能地检测多项目存储库，并为每个项目运行适当的扫描仪并报告漏洞。对于具有多项目存储库的用户，这将使用户更轻松，更简化地利用安全工具。未来的更新将进一步改善这些类型项目的仪表板和报告功能。

支持加密的LDAP凭证

GitLab使用统一的配置文件，例如gitlab.rb在Omnibus GitLab中，这使跨所有捆绑服务的配置变得容易。此配置文件中包含一些机密，比如用于验证LDAP服务器的凭据。虽然访问此文件确实需要提升的特权，但是最佳实践是将机密与配置分开。

Omnibus GitLab和Source安装现在支持加密的凭据，支持的第一个凭据是LDAP。这降低了GitLab配置文件的敏感性，还有助于达到客户合规性要求。

改善MR体验以进行安全扫描（PREMIUM及以上）

现在，SAST和秘密检测可用于所有使用级别，改善了所有GitLab用户在合并请求中与安全扫描结果进行交互的体验，从而使任何人都可以更轻松地访问安全扫描结果。以前的安全扫描结果只能在“管道概述”页面上访问，并且必须知道在哪里可以找到它们。现在，所有合并请求将显示是否已运行安全扫描，并帮助用户找到作业工件。此更改不会更改Ultimate用户的MR体验。

漏洞的特殊参考（ULTIMATE）

Gitlab在12.10中将漏洞作为一流对象引入。成为一流对象意味着每个对象都有一个唯一的URL，从而可以直接链接到任何漏洞的详细信息。尽管在可见性和一致性方面有了很大的改进，但仍然必须复制粘贴问题和史诗中的漏洞作为手动Markdown链接。与共享其他对象（例如问题）相比，这使得在GitLab其他区域中共享和引用漏洞更加麻烦且效率较低。

现在可以通过特殊引用链接漏洞。它们是第一个使用新[object_type:ID]语法的语言，该语法最终将扩展到其他现有引用。现在，可以从通常可以使用特殊引用（例如问题或合并请求注释）的任何地方快速插入指向漏洞的链接。例如，键入[vulnerability:123]问题注释以在同一项目中插入ID为123的漏洞的链接。还可以在ID前面加上名称空间或项目，以引用当前项目上下文之外的漏洞。

生成代码质量的HTML报告

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

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

性能改进

使用负载平衡器时，数据库查询速度更快

许多数据库查询会重复几次，并且可以缓存以提高整体性能。对于GitLab，大约所有查询的10%可以被缓存。在GitLab 13.7中，当使用数据库负载平衡时，Gitlab启用了数据库查询缓存，从而显着提高了整体性能。在GitLab.com上，这意味着每分钟缓存约700,000个查询，并将总请求时间缩短多达10%。

对于执行100个以上查询的请求，将请求持续时间缩短了11-31％，并将所有在数据库副本上执行的SELECT语句的30%缓存了。

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

漏洞报告加载更快；

漏洞状态和严重性计数更快地加载；

测试报告作业页面更快，响应速度更快；

活动用户计数许可证查询得到改进；

通过逐渐加载较大的批次来加快MR差异；

Bug修复

GitLab 13.7中一些值得注意的错误修复有：

漏洞标识符即使没有链接也显示为链接；

在漏洞报告中，项目选择器未显示组中的所有项目；

组安全仪表板显示不正确的漏洞计数；

npm包API速率限制导致管道失败；

NuGet包API速率限制导致管道失败；

最近的问题/史诗/ MR自动完成建议未显示标题完全相同的项目；

当项目搜索成功时，全局搜索找不到结果；

全局搜索匹配项在暗模式下很难阅读；

无法在Geo Secondary上列出容器存储库注册表和图像；

replicate-geo-database 全新的二次安装失败；

选择问题类型并关闭下拉菜单时，问题会立即提交；

当路线图上的史诗少于1000个时，错误地显示警告；

单击泳道侧边栏中的“编辑”标签后，下拉菜单只有在您单击下拉菜单后才会打开；

过期的迭代不会出现在边栏中；

功能删除

删除对CentOS 6支持

删除日期：2020年12月22日

CentOS 6于2020年11月停产。GitLab 13.6是在CentOS 6上部署GitLab的最后一个受支持版本。建议升级到CentOS 7或8。

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

变化日期：2021年1月22日

目前，GitLab支持：

应用程序日志的文本，JSON和logstash日志格式。

用于访问日志的文本，JSON和组合日志格式。

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

删除Container Registry日志Hook

变化日期：2021年1月22日

容器注册表当前支持只能用于电子邮件通知的日志记录Hook。

如今，基于日志条目的警报通常由单独的工具处理。据统计，Gitlab用户都不依赖此功能，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是容器注册表支持的错误报告服务之一。据所知，没有用户依赖此服务。为了简化和合并受支持的错误报告服务，打算、删除对Bugsnag的支持。

删除对NewRelic的Container Registry支持

变化日期：2021年1月22日

NewRelic是容器注册表支持的错误报告服务之一。据我们所知，没有用户依赖此服务。为了简化和整合支持的错误报告服务，打算删除对NewRelic的支持。

删除对TLS 1.0和1.1 Container Registry的支持

变化日期：2021年1月22日

出于安全性考虑，由于GitLab不再支持TLS 1.0和TLS 1.1。将对当前支持1.0（默认），1.1、1.2和1.3的GitLab容器注册表进行同样的操作，且默认为1.0。

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

在GitLab 14.0中弃用一键式GitLab托管应用程序

变化日期：2020年12月22日

在GitLab 13.7中，弃用一键安装GitLab托管应用程序。尽管对从GitLab部署到Kubernetes的入门非常容易，但是社区的总体反馈是，它们对于实际的Kubernetes应用程序不够灵活或不可定制。未来方向将集中在通过GitLab CI/CD在Kubernetes上安装应用程序，以便在易用性与扩展自定义之间取得更好的平衡。

计划在GitLab 14.0版中完全删除一键式托管应用程序。这不会影响集群中现有托管应用程序的运行方式，但是，将不再能够通过GitLab UI更新修改那些应用程序。建议集群管理员计划通过手动或通过CI/CD重新安装现有的托管应用程序

删除对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。

GitLab Runner安装程序忽略skel目录

变化日期：2021年6月22日

在GitLab Runner 14.0中，skel默认情况下，安装过程将在创建用户主目录时忽略该目录。

将pwsh设为新注册的Windows Runner的默认shell

变化日期：2021年6月22日

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

PostgreSQL 11支持

变化日期：2021年5月22日

PostgreSQL 12将是GitLab 14.0中最低要求的版本。它为索引编制，分区和一般性能优势提供了重大改进。

从13.7开始，新安装的GitLab将默认为PostgreSQL 12。要手动升级，请运行gitlab-ctl pg-upgrade。

在使用Patroni进行升级之前，多节点数据库实例将需要从repmgr切换到Patroni。然后可以更新GEO辅助数据库并重新同步。

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

删除日期：2021年6月22日

在GitLab转轮13.3，增加了应/user/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（版本3376）中，介绍了Shell执行器sigterm，然后介绍sigkill了该过程。我们还引入了一个新的功能标志，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL因此您可以使用以前的过程终止序列。

删除FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER功能标志

删除日期：2021年6月22日

在GitLab Runner 14.0中，将删除FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER功能标记。

删除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 runner13.2翻译step_script到build_script被添加到自定义执行。在14.0中，该build_script阶段将替换为step_script。

需要Git 2.29或更高版本

删除日期：2020年12月22日

在GitLab 13.7和更高版本中，GitLab需要Git 2.29或更高版本。Omnibus GitLab安装包括Git 2.29。从源安装必须手动升级。

与Opsgenie的直接链接将被删除

变化日期：2021年1月22日

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

删除Python 2对依赖性扫描的支持

删除日期：2021年12月15日

依赖性扫描不再支持2020年1月1日日落的Python 2（通过设置DS_PYTHON_VERSION:2）。如果需要Python 2，则需要使用容器版本v2.10.0（例如，registry.gitlab/gitlab-org/security-products/analyzers /retire.js：2.10.0）或更早的版本。

删除对Python 2的SAST支持

删除日期：2021年12月9日

自2020年1月1日起，Python 2便已终止生命周期（EoL）。作为维护和更新我们的基础SAST分析器的一部分，Gitlab更新了Bandit，它放弃了对Python 2规则的支持。如果仍然需要支持Python 2应用程序，则可以覆盖GitLab SAST CI模板以固定到支持Python 2的早期版本的Bandit。通过固定至先前的版本，将不会收到Python SAST分析器的最新更新。以下是可以放入SAST.gitlab-ci.yml模板中的替代代码段：

include:

- template: Security/SAST.gitlab-ci.yml

bandit-sast:

variables:

SAST_ANALYZER_IMAGE: "$SECURE_ANALYZERS_PREFIX/bandit:2.10.0"

升级更新

Omnibus版升级

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

yum updata/install gitlab-ce

就能自动完成升级：

docker安装的实例

停止和删除旧的容器：