上个月22日，GitLab官方blog按照惯例发布了有一个月度版本12.7。在12.7中，做了多项改进，包括父子管道，管道资源组、blame视图、结构化日志等。关于本次发布的功能介绍，请和虫虫一起学习。
主要功能介绍
父子管道
复杂的应用程序通常需要复杂的管道，这可能会导致执行变得缓慢且不好排查管理。随着管道复杂性的增加，其可视化会变得越来越笨拙，配置更加复杂，执行速度也变慢。此时，将复杂的管道分成多个管道（以父子关系进行组织）可以提高性能并使管道清晰：因为子管道可以同时运行，所以可以提高性能，而配置和可视化可以分为不同的部分文件或视图。新版本GitLab 12.7中，可以使用单独的YAML文件定义这些单独的管道。 .gitlab-ci.yml仍然是主要配置入口，但是可以在这个主配置中可以include任何其他YAML文件作为其自己的子管道，并归还给父管道。还支持使用include来促进这些不同管道之间的代码重用。
GitLab在线仓库Beta版Windows共享运行程序
GitLab托管的Windows Shared Runners推出测试版。可以利用该托管，实现自动缩放和安全的环境，可与GitLab在线仓库在同一GCP基础结构上的Windows虚拟机上运行CI/CD作业。 Windows Shared Runners已预先配置了各种软件包，例如Windows的Chocolately软件包管理器，Visual Studio 2019 Build Tools和Microsoft .Net Framework等。
当然也可以继续在自己的基础架构上安装和管理Windows Runner，以与GitLab团队管理的新可用GitLab在线仓库Runners一起使用或互相替换。
关于其相关说明、价格、限制和配置的更多信息，请参考Windows Runners beta官方相关文档。
管道资源组
大多数情况下，用户希望尽可能并行化其CI/CD，以加快总运行时间。但是，在某些情况下，可能希望限制并发性。例如，如果要防止作业在同一环境中同时在不同的管道中执行。当广泛使用诸如智能手机，计算机芯片或嵌入式IoT设备之类的物理硬件来运行测试之前，经常会看到这种情况。尝试从多个管道甚至同一管道中的多个作业同时运行测试可能会导致数据损坏，无效的测试结果，甚至使硬件变砖。
使用资源组，可以限制管道并发，以强制作业按顺序执行，从而确保仅按计划使用资源。使用.gitlab-ci.yml中的resource_group关键词，可以限制每个作业指定属于资源组一部分的环境。当作业请求运行程序并且资源已在运行现有作业时，它将一直排队，直到现有作业完成。例如，如果有多个用于测试的IoT设备，并且希望测试作业在组中的任何一台设备上运行，甚至可以为每个作业定义多个资源组。另一个很好的用例是使用Terraform将基础结构作为代码进行管理时，确保一次只对给定环境进行一次更改。
代码审查分析（STARTER及以上）
代码审查是任何软件开发过程的推荐部分，它使对等方和自动化过程能够检查对存储库的建议更改。
由于错过了交接，关键人员正在休假或待审核的项目积压，因此迁入的更新可能停滞在那里。周期时间取决于及时的代码审阅，以保持团队的运转。
为了帮助GitLab实例始终处于开发过程的关键部分，新版本中引入了代码审查分析以突出显示正在审核的合并请求的状态。
合并请求收到成员的commit后，代码审查分析便开始审查过程，并跟踪该合并请求已打开多长时间。表格中突出显示的合并请求以递减顺序显示审阅时间，因此很容易找到可能需要干预或进一步细分的合并请求。
显示合并请求的部署时间
新版本中，"合并请求"小部件会在每个合并请求中显示环境名称和部署时间。之前，为了确定上一次部署的时间，将需要遍历提交和管道列表以获取此信息。通过跟踪合并请求，开发人员将能够轻松查看其更改何时进入特定环境。
与其他组共享组访问权限
组可用于组织项目和组成员。典型的使用模式是为不同的团队创建组，例如开发，运维和运营，并对每个小组共享相关项目。
对于具有数千个项目的大型实例，与一组共享单个项目很快变得不可扩展。为了简化操作，新版本引入了与另一个组共享一个组的功能，而无需与一个组共享单个项目链接。
新增"不是"运算符（!=）筛选，支持过滤问题、合并请求、Epic和问题面板
精确查找所需的问题，合并请求和Epic可能很困难，尤其是当你想要省略结果的子集时。新版本中支持在使用（!=）运算符在问题面板中过滤问题，合并请求，Epic和问题列表。
Blame视图浏览文件更改历史
Blame视图允许逐行跟踪文件的历史记录，并检查每次提交。在GitLab 12.7中，可以在更改之前使用标题为View blame的新按钮轻松跟踪特定行的历史记录。
允许在依赖项扫描中配置pip版本（ULTIMATE）
在GitLab 12.7中，可以使用DS_PIP_VERSION变量在"依赖关系扫描"中安装自定义版本的pip。设置此选项后，它将向下传递到"依赖关系扫描"分析器。
发布的审计事件（STARTER及以上）
在GitLab版本中更进一步，自动在GitLab审核日志中包含创建或编辑版本，下载工件以及关联或解除里程碑的事件，从而使过程审计更加轻松。
使用CI/CD更新Conan存储库（PREMIUM及以上）
GitLab 启动了Conan存储库，以支持C/C++开发人员发布和下载其依赖项。但是，在为了利用GitLab CI/CD，必须使用其用户名和密码，这样效率低下并且存在潜在的安全风险。
GitLab 12.7中，用户现在可以利用预定义的环境变量CI_JOB_TOKEN对他们的Conan存储库进行身份验证，并轻松发布和安装其依赖项。
禁用用户个人资料名称更改（PREMIUM及以上）
管理员现在可以防止用户更改其个人资料名称，以提高用户操作的可追溯性。对身份的附加控制将使注重合规性的组织能够确保GitLab支持其内部策略以进行审核日志记录和身份验证。
这是一个全局实例级功能，需要管理访问权限，并且当前仅适用于自建GitLab实例。
用于与部署关联的合并请求的API
新增加了API支持，可用于检索给定部署中随附的合并请求列表。这对于跟踪合并请求何时合并到特定环境中很有用。
增加GitLab CI/CD分步部署指南
在对应用程序进行更改时，可以选择只发布到部分Kubernetes Pods节点，用来降低风险。采用逐步上线（灰度发布）策略，可以监视错误率或性能下降，如果没有问题，则可以更新所有节点。GitLab支持使用增量式对Kubernetes生产系统的手动触发和定时式部署，以支持持续交付和持续部署的应用程序。该策略已经在Auto DevOps项目中可用。新版本提供一份新指南，显示仅使用GitLab CI/CD时如何获得相同的结果。
直接从列表中切换功能标志（PREMIUM及以上）
通过功能标志，可以在生产环境中启用或禁用最近引入的功能，以降低在完全测试功能之前破坏应用程序的风险。新版本中可以直接在功能标记列表中一键在GitLab中打开或关闭标记。而此前需要使用API实现切换。
忽略GitLab中的Sentry错误
错误有可能是多而嘈杂，这导致分类过程很耗时，很难通过分类来找到关键错误。能够忽略GitLab用户界面中的错误，可以使我们清除不需要关注的错误，以便可以轻松地专注于需要修复的错误。忽略非严重错误使错误列表易于扫描和分类。可以在错误的特定详细信息页面和错误列表上找到"忽略"按钮。
Sentry错误详细信息页面上的语言和紧急信息
错误的分类具有挑战性，因为它们嘈杂，并且难以找到相关信息。GitLab中的错误详细信息页面显示了错误的最重要属性。在GitLab 12.7中，这些详细信息现在包括语言和紧急度，用来帮助尽快确定错误的根本原因。
在Sentry错误详细信息页面上链接到GitLab提交
遍历堆栈跟踪非常麻烦，而不必确定哪个版本影响了受影响的文件。在GitLab 12.7中，最有可能导致错误的提交会自动显示在错误详细信息页面上。能够自动将提交与可疑错误相关联，可以大大减少解决错误的时间。这使我们能够立即回滚更改，或使用补丁程序对其进行修复。
请注意，为了利用此功能，需要使用已部署提交的SHA来命名Sentry Release对象。
解决GitLab中的Sentry错误
一旦确定了错误的根本原因，就部署了修补程序并验证了其成功（全部来自GitLab）。使用GitLab 12.7，现在只需单击一个按钮，就可以解决错误而无需切换到Sentry。在错误的特定详细信息页面上可以找到"解决"按钮。
应用建议配置默认提交消息
建议合并请求中的更改使提出改进建议变得容易。但是，如果使用推送规则要求所有提交消息都采用特定格式，则在大多数情况下，无法应用建议的更改，因为GitLab生成的提交消息与推送规则的验证模式不匹配。
在GitLab 12.7中，支持在应用建议的更改时为GitLab创建的提交配置提交消息模板，因此根据提交消息推送规则，设置才有效。
自动链接Rust软件包名称
浏览项目时，查看其依赖项通常很有用，但是依赖项通常存储一个链接文件中。
新本中，在查看Rust项目的Cargo.toml依赖项配置文件时，GitLab将检测用的依赖包并将其链接到crates.io，以便于理解其依赖项。之前的GitLab 9.3中已经添加了对Go，Ruby，Node.js，Python，PHP和Objective-C等语言项目的支持。
查找SSH并通过MD5和SHA-256指纹部署密钥
2015年OpenSSH（6.8）默认的指纹算法默认切换到SHA-256，显示SSH密钥的MD5哈希值将没多大意义。现在可以同时看到SSH和部署密钥的SHA-256指纹，并支持通过新添加的API来通过密钥指纹查询用户：
curl --header "PRIVATE-TOKEN: <your>" '/api/v4/keys?fingerprint=SHA256%3AnUhzNyftwADy8AH3wFY31tAKs7HufskYTte2aXo%2FlCg/<your>
重复指标仪表板
GitLab开箱即用，带有许多有用的指标仪表板，用于监视应用程序的运行状况。在12.7中，可以轻松地复制这些默认仪表板之一，以便进行少量自定义以添加例如应用程序的特定系统或业务指标。
要求所有用户登录才能访问GitLab Pages网站
新版本中，GitLab Pages具有一种与项目隐私设置分开的禁用非授权访问的方法，这样即使对公开项目的Pages站点可以设置要求用户登录才能访问。GitLab管理员可以通过页面管理设置中的复选框启用此设置。
对Elasticsearch 7.x的支持（STARTER及以上）
在GitLab 12.7中，更新了索引器和GitLab的依赖关系，以支持Elasticsearch 7.x和现有的对Elasticsearch 6.x的支持。这是Elasticsearch集成中最需要的功能。过更新以支持Elasticsearch 7.x，还发布了索引器的2.0.0版本，该版本正式提供了此支持。如前所述，GitLab不再支持Elasticsearch5.6.x。
项目所有项目服务的API路线在/projects/:id/services下可以使用新的API路由，该路由提供了给定项目的所有活动项目服务的列表。
获取活动服务列表的功能使开发人员可以更轻松地通过API以编程方式在其项目中添加和编辑服务。
使用结构化的应用程序日志记录和分析实例活动
GitLab的日志系统使管理员可以监视和评估日志文件，以更好地了解实例的状态。这些日志具有广泛的用例，包括性能监视，分析和系统审核。
但是，某些日志仅以非结构化格式提供，使其难以解析。这些非结构化日志之一为application.log，该日志记录了应用程序的活动，包括项目，组和用户事件。在12.7中，GitLab中引入了更加灵活的日志记录系统，以application_json.log的形式引入了JSON格式的application.log。
创建此日志文件的结构化版本会开辟很多有意思的用例，例如，将其纳入监视工具以进行事件审核，将这些事件发送到可视化工具以构建自定义的仪表板，等等。
直接从Epic创建问题（ULTIMATE）
不再需要通过多个选项卡进行切换来创建问题并将其分配给史诗。现在，可以直接从Epic视图创建问题。
从电子表格剪切并粘贴Markdown表
将表格数据整合到Markdown中可能是一个繁琐而费力的过程。从12.7开始，你现在可以从电子表格中复制内容，将其直接粘贴到GitLab中的Markdown编辑器中。编辑器会自动将电子表格转换为有效的Markdown语法，不用浪费时间进行格式化，将更多的时间用来创造更有意义的工作。
注意虫虫对该功能测试结果是在问题编辑器中是有效果的，而在给仓库中文件的编辑器后者Web IDE中都是不支持的。
自动暂存Web IDE中的所有更改
GitLab中的Web IDE是很棒的在线进行项目更改的工具。但是，其文件的持久性是一个问题。用户可能会更改多个文件，但是在离开Web IDE页面浏览之前，并不能保证所有更改都被暂存和提交，可能会导致这些更改丢失。
为了使Web IDE对用户更易于访问并防止出现意外丢失情况，新版本中将自动暂存Web IDE中的更改。当用户单击"提交"时，提交屏幕将使他们能够添加其提交消息并选择其分支，而不是提供暂存更改的选项。
从用户界面删除管道
此前，只能通过API删除管道。从12.7版开始，拥有项目所有者权限的用户可以单击新的"删除"按钮直接从"管道详细信息"页面中删除特定管道。这个不可逆操作将使管道缓存过期，并删除所有相关对象（构建，日志，工件和触发器）。
能够从UI删除管道的主要好处是，如果管道中的作业以纯文本形式公开私钥，则可以立即采取行动以保护泄露的机密。另一个一个更常见的用例是需要清理混乱的CI历史记录，该历史记录中充满了由于CI配置尝试或实验导致的失败管道；清理的另一个好处是可以确保不会意外使用不需要的管道。
查看设计时放大（PREMIUM及以上）
当将问题（如宽屏网站布局）上传到问题的"设计"选项卡时，由于图像显示在固定宽度的窗口中，因此很难看到图像的细节。新版本中现，支持放大设计，因此可以深入了解细节。在图像底部找到缩放控件。
Auto DevOps运行检查
对于任何项目，Auto DevOps是入门现代DevOps实践的好方法。但是Auto DevOps仍需要运行CI管道来通过检查项目是否存在Dockerfile或匹配的buildpack来确定与项目的兼容性。为了提高效率，并利用GitLab CI中的workflow:rules新功能，只有在项目包含Dockerfile或项目语言存在匹配的buildpack时，Auto DevOps才会运行。
使用CI模板安装Kubernetes应用程序
使用GitLab CI安装Kubernetes应用程序是一种在安装之前自定义Helm Chart和自定义资源（CRD）的好方法。新版本中添加用于使用GitLab CI安装Cert-Manager以及GitLab Runner的模板。通过GitLab CI安装GitLab Runner掌舵图，用户可以配置以前无法执行的设置，例如并发作业数或作业检查间隔。
从服务台创建电子邮件回复模板（PREMIUM及以上）
现在可以根据组织自定义Service Desk电子邮件回复，只需将模板Markdown文件添加到存储库中，并且Service Desk响应用户时，就会自动使用该模板。这将允许自定义品牌和消息传递为客户提供最佳体验。
将用户模板附加到收到的服务台问题（PREMIUM及以上）
服务台允许通过向唯一地址发送电子邮件来创建新问题。创建这些新服务台问题后，如果可以将它们自动分配给特定用户，给定标签或分配给里程碑，则将是有益的。新版本中，可以通过创建要包含在所有新服务台问题中的模板来做到这一点。在模板中包括任何快速操作，它们将在创建问题时激活。
Geo支持复制设计管理资产（PREMIUM及以上）
GitLab设计管理允许用户将设计资产（例如，模型）上载到GitLab问题，并将其存储在一个地方。
GitLab Geo现在支持将这些设计管理资产复制到辅助节点，以确保分布式团队可以从最近的Geo节点访问它们。由于设计管理资产已复制，因此也可以从辅助节点还原它们。
目前还不支持对这些资产的验证，并将在以后的版本中增加支持。
外观API
新版本中，可以通过新的API调整实例的外观设置，包括实例标题，描述，图标，徽标等属性。
改进了差异突出显示的合并请求建议
使用"建议的更改"提出对"合并请求"的改进建议，通过应用更改并单击解决解决方案，可以使协作更加轻松。
在GitLab 12.7中，改进了diff突出显示了建议的更改，让我们清楚哪些单词和字符已更改，因此可以放心地应用建议，一键修改。
禁用自动关闭合并请求中的问题
每个团队都有独特的需求。通常，有必要在单个合并请求的生命周期之外保持问题处于打开状态，或者在提交中引用问题而不试图关闭问题。
在此版本之前，团队无法通过在合并请求或提交中提及问题来禁用自动关闭问题的默认行为。为了向团队提供对该功能的更精细控制，现在可以在项目设置中禁用自动关闭问题。
改善了/projects API初始响应时间
在GitLab 12.7中，对/projects API的首页响应时间进行了显着改进。此前，对于某些参数组合， GitLab官网上看到的响应时间高达30秒。通过改善，现在大多数响应将在一秒钟之内。请注意，无论使用哪种分页策略，这些改进都适用。
使用keyset分页加速/ projects API
为/projects API端点引入了新的分页机制。以前，基于偏移量的分页是唯一可用的方法，该方法虽然提供了灵活的排序和过滤选项，但对请求的每个页面的执行效果却越来越差。这种不良的性能特征使GitLab服务器的负载增加，并且响应时间越来越长。
在GitLab 12.7中，引入了基于keyset的分页。尽管此方法仅允许基于项目ID进行排序，但是无论请求的是哪个页面，它的执行速度都非常快，响应时间能保持很短。将keyset分页用于检索许多页面的查询，既可以减轻GitLab服务器的负担，又可以加快数据检索的速度。
预计在12.10中，将为基于偏移的分页实现可配置的页面深度限制，默认深度为10,000条记录。10,000的限制将在12.10中在GitLab线上仓库上强制执行。
使用API时，允许基于配置项跳过CI
在提交消息中使用CI skip（或跳过ci）或通过使用push选项时，已经可以跳过CI管道的创建，但是在重新rebase时无法跳过CI。从12.7版开始，现在可以使用rebase API。
Omnibus的改进
Omnibus GitLab中捆绑的Redis版本已从Redis 3.2.12更新到Redis 5.0.7，这使GitLab拥有最新的Redis稳定发行版。Redis 5包括许多改进。有关Redis 5中所做更改的更多信息，请参见Redis发布公告。升级后，需要手动重新启动Redis。更多升级说明，见本文最后的有关升级到GitLab 12.7的重要说明。
如果尝试升级时仍在进行后台迁移，则某些版本之间的升级有时会失败。文档已添加到更新GitLab中，该文档说明了如何检查后台迁移是否仍在运行。
GitLab中包含的Ruby版本已从2.6.3更新到2.6.5，以包括一些修复程序和安全补丁。
添加了有关如何使用EXTERNAL_URL环境变量的文档，以使其更易于启动和运行GitLab实例。
GitLab Runner 12.7
同时还发布了GitLab Runner 12.7。一些改进包括：
在Docker执行程序中允许来自配置的服务别名
修复了"在没有配置裁判的情况下，Kubernetes执行者的恐慌"
升级到Go 1.13.5
性能改进
GitLab 12.7中的一些改进包括：
删除preset_group_root功能标志。
添加里程碑日期来源外键。
允许Gitaly引用名称缓存进行问题讨论。
防止大量用户引用导致堆栈溢出。
里程碑燃尽图的性能改进。
将RelativeLinkFilter拆分为UploadLinkFilter和RepositoryLinkFilter。
对路线图Epic使用缓冲渲染
导入：预加载项目，用户和组以重用对象
导入：添加importing?禁用一些回调
导入：GroupProjectObjectBuilder的LRU对象缓存
GitLab Chart 3.0
与GitLab 12.7一起发布的GitLab Chart 3.0是GitLab Helm Chart的新主要版本。由于此版本中的重大更改，升级需要执行其他步骤，并且应按照升级文档进行。GitLab Chart 3.0包括许多组件的功能改进和更新，下面概述了每个组件，并链接到GitLab Chart 3.0史诗。
GitLab hart使用nginx-ingress Chart的分支。GitLab Chart 3.0引入了在上游nginx-ingress图表中所做的更改，以确保GitLab与Helm 2.15.0和Helm 3兼容。
Kubernetes 1.16中不再支持extensions/*和apps/beta* API版本。GitLab使用的多个上游Chart已更新，以停止使用这些API版本。GitLab Chart 3.0包括更新的上游Chart：Prometheus Chart9.4.x，PostgreSQL Chart 7.7.0和Redis Chart 10.3.x（不再fork）。
Sidekiq部署现在使用唯一的选择器，以避免在创建多个部署时混淆哪些部署拥有一组sidekiq容器。有关升级Sidekiq部署的重要信息，请参阅升级文档。
添加了文档，以提供有关将GitLab连接到用于对象存储的外部Minio实例的说明。
GitLab Chart不再管理GitLab操作员CRD（Kubernetes自定义资源定义）的生命周期。现在可以直接使用kubectl完成CRD的安装。有关安装CRD的新说明，请参阅GitLab Operator安装文档。
禁用gitaly的标志已移至全局设置。这简化了禁用Gitaly的过程，因此不再需要跨服务编辑多个设置。有关如何禁用Gitaly以利用外部Gitaly服务的新说明，请参阅使用外部Gitaly配置文档。
功能弃用
GitLab 13.0中删除PostgreSQL 9.6和10.x的支持
为了利用PostgreSQL 11中改进的性能和功能（例如分区），计划在GitLab 13.x中要求PostgreSQL 11和12版本。为此，将在即将发布的GitLab 12.x版本中引入对PostgreSQL 11的支持，同时保持对9.6和10.x的支持。到GitLab 13.0中，将最低需要PostgreSQL 11版本。
通过最低要求PostgreSQL 11，能够利用引入的新功能，而无需维护多个代码分支。展望未来，Gitlab将保持PostgreSQL升级的年度节奏，并在能够添加第二和第三最新版本后对其进行支持。
生效日期：2020年5月22日
/projects的偏移分页限制为10,000
在GitLab官网上将基于偏移量的分页限制10,000应用于GitLab 12.10中的/projects API端点，默认情况自建实例启用。进行偏移量大于10,000的API调用的集成将需要切换到基于Keyset分页方法，这将显着缩短响应时间并减少GitLab服务器上的负载。自建实例将能够将限制自定义为所需的值。
为了提供优化的性能，基于Keyset分页仅提供基于项目ID的排序。如果偏移量保持在限制以下，则需要更灵活选项的用例可以继续使用基于偏移量的分页。如果用例需要具有较大偏移量的灵活排序选项，则建议对客户端进行排序。
变化日期：2020年4月22日
升级更新
Omnibus版本升级
Omnibus安装的自建实例可以使用包管理器可以升级。
CentOS: yum updata/install gitlab-ce 就会自动完成升级过程。
docker版本升级
先停止和删除旧的容器
sudo docker stop gitlab
sudo docker rm gitlab
拉取gitlab官方最新的镜像：
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 12.7的重要说明
Omnibus GitLab打包的Redis版本已更新到Redis 5.0.7。升级你的GitLab实例时，你将需要在升级后重新启动Redis，以便新版本处于活动状态。
要重新启动Redis，请运行： sudo gitlab-ctl restart redis。
如果你的实例具有使用Sentinel的Redis HA，则你需要按照特定的升级步骤进行操作，这些步骤与Omnibus GitLab软件包一起安装的更新GitLab中记录，以避免停机。
GitLab 12.7致力于实现性能更高的差异视图。作为这项工作的一部分，我们更改了差异在Redis缓存中的存储方式。随着缓存开始接收流量，升级其GitLab安装的用户可能会看到Gitaly负载暂时增加。如果这严重影响可用性，请禁用hset_redis_diff_caching功能标志。
此版本的GitLab映射到GitLab Chart的主要版本GitLab Chart 3.0。如果你已使用Helm Chart安装了GitLab，则需要采取一些手动步骤从以前的版本升级到GitLab Chart 3.0。有关分步说明，请参阅官方文档。
Helm 2.15.x包含影响GitLab Helm图表使用的错误。不要将Helm 2.15.x与GitLab Chart一起使用。有关Helm的受支持版本，请参阅官方文档。
閱讀更多 蟲蟲安全 的文章
