GitLab 13.11发布，新增加K8S代理和管道合规等

4月22日是世界地球日，善待地球，保护我们的环境！今天Gitlab也发布月度版本13.11。新增加的功能有GitLab Kubernetes代理，可是实现基于拉的一键进群部署。兼容管道配置，可以定义可强制执行的管道，管道中可以配置好相应遵从框架的任何项目（甚至是自定义框架）运行。更多功能，请和虫虫一起学习。

概述

控制可以使自动化随着团队成长和扩展而步入正轨，也能减轻合规性工作任务。GitLab新推出的以Kubernetes代理为核心，通过GitLab的Kubernetes集成支持基于拉的部署，这是安全性首选的部署，并迅速成为Kubernetes部署实践的流行方法。代理还支持 络安全策略集成和告警，告警可在群集中启用微调的RBAC控制。符合要求的管道配置可以通过定义可在分配了相应合规性框架的任何项目中运行的可执行管道来实施更高程度的职责分离，并降低业务风险。

同时，自定义合规框架标签，可以自定义要求，而不是PCI，HIPPA等统一性的要求求。

通过要求管理员用户在运行管理命令之前重新验证，新的管理员模式提高了对GitLab实例的安全性和控制力。

新的基于Semgrep的灵活规则语法以扩展和修改自定义检测规则，让GitLab SAST更加灵活和强大。通过增加了对自定义证书和密钥到期电子邮件告警的支持。现在，可以通过对Git活动强制执行SAML来改善安全状况。

新的呼叫中心计划管理在GitLab中收到的告警路由到该项目的时间表中的On-call工程师。随着安全告警日趋成熟，该计划管理将特别有用，它可提供有价值的事件管理功能，并在整个DevOps流程中具有端到端可见性。

主要功能

GitLab SaaS的GitLab Kubernetes代理（PREMIUM及以上）

GitLab Kubernetes代理可在GitLab SaaS上获得。通过使用代理，可以受益于对群集进行快速，基于请求的部署，而GitLab SaaS可以管理代理的必要服务器端组件。 GitLab Kubernetes代理是GitLab Kubernetes集成的核心构建块。基于代理的集成支持基于请求的部署以及Network Security策略集成和告警，并且不久还将获得对基于推送的部署的支持。

与传统的基于证书的Kubernetes集成不同，GitLab Kubernetes代理不需要向GitLab开放集群，并可围绕集群中GitLab的功能进行微调的RBAC控件。

呼叫中心时间表管理 （PREMIUM及以上）

客户往往期望24/7全天候可用。 当出现问题时，需要一个随叫随到的On-Call团队（或多个团队！）来快速有效地响应服务中断。

为了更好地管理压力和精疲力尽，大多数团队内部会轮流值班。GitLab的On-Call值班时间表管理功能使团队可以创建和管理通话职责的时间表。通过HTTP接口在GitLab中收到的告警将在该特定项目的时间转呼给值班工程师。

管理区管理员模式

Gitlab引入管理员模式，它可以帮助管理员从一个帐户安全地工作。当“管理模式”处于非活动状态时，管理员具有与普通用户相同的特权。在运行管理命令之前，管理员用户必须重新验证其凭据。管理员模式通过保护敏感的操作和数据来提高实例安全性。

导出用户访问 告（PREMIUM及以上）

注重合规性的企业经常需要审查其用户对公司系统和资源的访问权限。GitLab中要实现这一目标，需要使用构建自定义工具，审计相关的API以组装所需的数据。

新版本中，只需点击点击管理区域导出按钮，就可以导出成CSV文件，文件包含每个用户以及他们有权访问的组，子组和项目的列表。

在同一作业中使用多个缓存

GitLab CI/CD提供了一种缓存机制，可以在作业运行时节省宝贵的开发时间。 以前，不可能在同一作业中配置多个缓存键。该限制可能导致使用工件进行缓存，或将重复的作业用于不同的缓存路径。在此版本中，提供了在单个作业中配置多个缓存键的功能。

变更指标的DORA 4提前期跟踪

衡量软件开发生命周期的效率是任何组织提高DevOps使用率的重要步骤。之前，GitLab添加了API支持为更改的交付时间项目级别。这些指标可以指示吞吐量，因此可以知道提交代码并将其部署到生产环境所花费的时间。在新版本中，可以通过CI/CD仪表板在GitLab UI中访问该功能，新图表将显示更改的前置时间，并具有查看不同时间范围视图的功能，例如上周，上个月，或最近90天。并且还在组级别上添加了对该API的支持，使可以从属于该组的所有项目中获取变更指标的汇总提前期。

用于问题和合并请求的实例和组描述模板（PREMIUM及以上）

新版本中，多个项目可以使用单个仓库集中管理和获取模板。相关实例和组级别的文件模板扩展，以include发出和合并请求描述模板。当在.gitlab目录创建一个文件模板，则该模板可以用于属于该实例或组的所有项目。每个组或子组还可以设置一个附加的模板存储库，这将使来自多个文件模板存储库的模板能够级联到子组和项目。

CI/CD管道中的可选DAG (‘needs:’)作业

GitLab CI/CD中的有向无环图（DAG）使可以使用 needs语法，用于将作业配置为比其阶段更早。也支持rules，only，或者except关键字，用于确定是否将作业完全添加到管道中。但是，当needs 与其他关键字一起使用时，如果未将依赖作业添加到管道中，则管道可能会失败。

在此版本中，添加optional关键字needs DAG作业的语法。如果一个依赖的工作被标记为optional但不在于管道中，needs工作会忽略它，如果工作是optional并出现在管道中needs作业等待它完成后再开始这样可以更轻松地安全组合rules，only，和except。

组级别的特定于环境的变量（PREMIUM及以上）

许多组织更喜欢在组级别指定密码和其他环境变量，因为它与团队边界或信任级别非常吻合。到目前为止，组级环境变量会影响所有环境，这在许多用例中都限制了它们的可用性。新版本中，支持组级别发布特定于环境的变量。

该更改补充了项目级别的类似功能。从现在开始，组维护者可以指定要应用给定变量的环境。

使用GitLab Operator（beta）在OpenShift和Kubernetes上部署GitLab

GitLab正在努力提供对OpenShift的全面支持。新发布了MVP GitLab Operator。用来在Kubernetes和OpenShift容器平台上管理GitLab实例的整个生命周期。不过，这一个beta版本，不建议用于生产环境。下一步将是使Operator普遍使用（GA）。将来，尽管仍会支持GitLab Helm图表，但该操作员将成为Kubernetes和OpenShift的推荐安装方法。

看板添加迭代列表

看板现在支持创建迭代列表。将问题从一个迭代快速转移迭代在计划板上到另一个，或使Epic能够在即将到来的迭代中有效地对Epic问题进行排序。

项目的活动集成现在显示在设置菜单

新版本中，活动集成显示在页面的菜单中，用户可以更清楚使用的内容，并且更容易最关心的集成。

Cherry Pick从fork提交给父对象

使用GitLab 13.11，项目成员可以从下游分支中挑选出一些承诺，然后再将其提交回项目中。在cherry-pick对话框中添加了一个新的“Pick in project”部分，当在提交的详细信息页面上选择“选项”>“ Cherry-pick”时显示。

贡献者 区可以为的项目做出贡献，团队不再需要手动下载fork的.patch文件来从陈旧或未维护的fork中获取良好的更改。

未来的增强功能包括从一个分支到另一个分支的Cherry Pick选择提交。

Jira Connect应用程序配置的改进

当配置用于Jira的GitLab SaaS时，可以在将可用的名称空间链接到的帐户时对其进行过滤，从而简化了可访问大量名称空间的用户的配置。

为fork中的合并请求设置默认目标项目

Fork项目后，使用合并请求为上游项目做出贡献可能会有所帮助。之前GitLab假定来自fork项目的合并请求将始终以上游项目为目标。这可能会导致不应该在上游进行代码合并的错误步骤，或者用户需要在打开合并请求之前进行更改。

新版本中，GitLab现在支持在fork项目中创建的合并请求设置默认目标项目。

违反代码质量的程度按严重性排序

在项目上运行代码质量扫描可以发现数十到数千个违规。在“合并请求”小部件的较小视图中，当通过大量代码质量违规排序时，可能很难先确定最关键的问题要首先解决。

新版本中，“代码质量合并请求”小部件和“完整代码质量 告”默认均按严重性对违规进行排序，以便可以快速识别要解决的最重要的代码质量违规。

从版本控制下载Composer依赖项

下载Composer依赖项时有两个选项：source或dist。对于稳定版本，dist默认情况下，Composer使用并将依赖项下载为zip文件。但是，也可以直接从版本控制中下载它。如果启用–prefer-source，Composer会将依赖项下载为Git克隆而不是打包的zip文件。如果要为项目进行错误修复并直接获取依赖项的本地Git克隆，这将很有用。

直到最近，还无法在下载Composer依赖项时使用prefer-source和相关的preferred-install命令和配置。这使许多人无法将GitLab软件包注册表使用Composer依赖项。

新版本中，可以使用–prefer-source从源代码下载Composer依赖项：

composer update –prefer-source。

共享打包和容器注册表的过滤视图

可以使用GitLab软件包和容器注册表来发布和共享项目的依赖项。当在GitLab中查看注册表时，可以对结果进行过滤和排序，以查找和验证所需的项目。之前，无法与队友共享注册表的过滤视图。这样团队成员需要花时间过滤视图。这效率低下，并带来了可能安装错误的依赖项的风险。

在GitLab 13.11中，可以通过简单地从浏览器复制URL并将其与团队共享来共享注册表的过滤视图。

Geo支持管道工件（PREMIUM）

Geo现在支持将管道工件复制和验证到从站点，从而允许分布式团队从最近的Geo站点访问它们，这减少了延迟并改善了整体用户体验。Geo会自动验证复制的管道工件的数据完整性。这确保了管道工件在传输或静止时不会损坏。如果将Geo用作灾难恢复策略的一部分，则可以保护客户免受数据丢失的影响。

根据状态过滤要求（ULTIMATE）

要知道产品的哪些区域需要其他测试或不完整，新版本中可以根据状态过滤需求列表。由于可以通过CI/CD管道作业来满足需求，因此需求的状态始终是最新的。

添加独立评论以合并请求评论

在查看更改时，可能希望总结反馈，或对与特定更改无关的内容发表评论。在GitLab只允许评论更改或答复现有评论，这意味着其他种类的意见提交了审查后作出。

强制推送受保护分支的选项

Git强制推送危害很大，危害很大，危害很大！所以一般通过保护分支来，防止该操作。但是在特殊情况下有时可能会需要它。临时删除分支保护可能并不是很理想的方法。

GitLab 13.11为受保护的分支引入了新的“允许强制推送”设置，使“允许推送”白名单列表中的用户可以强制推送。

搜索设置项

GitLab设置项复杂而繁琐，找到一个确切的配置项很费时间。即使知道在哪里查看，许多设置视图还也包含多个部分和数十个单独的配置选项。

在新版本中，现在可以使用组、项目，管理员和用户设置中的搜索字段来快速查明所需的配置搜索条件将向下过滤配置页面，以仅显示相关设置，甚至突出显示该页面上出现的搜索词。

在未来的迭代中，会扩展此功能以在所有设置视图中进行搜索。

VS Code中GitLab工作流程欢迎视图

Visual Studio Code（VS Code）的GitLab工作流扩展入门需要一些手动步骤才能将其连接到GitLab。如果扩展名设置不正确，或者是第一次设置扩展名，可能很难验证是否正确配置了扩展名。

在VS Code内的GitLab工作流窗格中，现在有一些步骤可帮助入门。它还会告诉当前的工作空间是否包含GitLab项目。

使用SemVer发布和安装通用软件包

可以使用GitLab软件包注册表来发布和共享通用软件包文件。可以使用命令行来执行此操作，但是很可能使用GitLab CI/CD来发布大多数文件。

在GitLab 13.11之前，对文件名GitLab验证阻止上传具有语义版本（SemVer）的软件包。由于SemVer通常用于将文件标记为与给定版本或分支相关，因此这使许多人无法在管道中使用程序包注册表。

GitLab 13.11放宽了文件名验证，因此可以使用SemVer来命名文件。希望该更新可以帮助用户采用程序包注册表，并使命名，验证和验证通用程序包更加容易。

Composer v2与GitLab软件包注册表一起使用

可以使用Composer将PHP依赖项发布，共享并下载到GitLab项目。六个月前，发布了Composer的新主版本（v2），并进行了多种更改，包括显著的性能改进，体系结构更新和运行时功能。

但是，一直以来都无法正常利用这些改进，因为GitLab注册表不支持Composer v2。新版本中添加了一个接口GET group/:id/-/packages/composer/p2/:package_name，该接口返回存储库中所有软件包的元数据。当Composer查找软件包时，它将替换%package%为软件包名称并获取该URL。

请注意，有两个参数是可选的，增加对providers-api和list-api参数的支持。

集成自建Prometheus

通过将群集服务与GitLab集成，可以受益于各种GitLab功能，例如环境面板，Prometheus度量标准和应用程序日志。之前功能要求使用不适合用户的工作流程和要求的GitLab托管应用程序。

在新版本中，可以通过GitLab服务与Prometheus和Kubernetes集成，并按照个性化的公司流程和政策，对它们进行最终维护。对新用户，GitLab也提供广泛的文档和建议的工作流程，介绍如何安装这些应用程序。

Geo验证复制的版本化摘要（PREMIUM）

Geo会自动验证复制的Versioned Snippets的数据完整性。这样可以确保摘要在传输过程中或静止时都不会损坏。如果将Geo用作灾难恢复策略的一部分，则可以保护客户免受数据丢失的影响。

在下一次迭代中，一旦检测到验证不匹配，将实现自动修复。Geo的验证功能通常在Geo的复制框架中实现，我们计划将验证应用于所有其他复制的数据类型。

Omnibus的改进

GitLab 13.11中，引入了Mattermost 5.33，其中包括在删除反应表中的反应时进行的软删除。对于HTTP版本低于1.1的WebSocket握手会导致警告，并且服务器将透明地将版本升级到1.1以符合WebSocket RFC。

在将来的Mattermost版本中将删除此功能，强烈建议修复代理配置以正确使用WebSocket协议。

Gitlab Runner 13.11

一起，还发布了GitLab Runner 13.11。新的功能和变化有：

Node.js项目的缓存速度更快；

允许用户为Kubernetes执行程序指定多个拉策略；

Bug修复：

使用kubectl attach非root用户时的权限错误；

Docker执行器中的GID检查使用错误的方法；

docker+machine执行程序创建失败时跳过VM设置；

Kubernetes执行器不会在构建日志中扩展镜像变量。

GitLab Helm chart改进

Sidekiq图表中现在可以使用Sidekiq中的配置选项terminationGracePeriodSeconds，可以在Pod节点关闭期间更好地保护长时间运行的作业。

之前，如果用户将设置SIDEKIQ_TIMEOUT为大于terminationGracePeriodSeconds的值，则没有任何保护措施。这将导致继续运行超过30秒的作业被强行停止。在新版本中，Sidekiq部署现在可以具有不同的超时时间。

现在支持服务帐户访问外部对象存储的IAM角色。

Bug修复

13.11中一些值得注意的错误修复是：

使用CI_JOB_TOKEN在其他名称空间安装npm软件包失败，并显示404。

项目级的Conan APIdownload_urls返回损坏的URL。

在组级别修复提取软件包所需的权限。

LinkMergeRequestWorker的性能改进，用于针对GitLab SaaS的Postgres primary运行SQL查询。

安全中心项目选择器不会为Auditor用户返回任何结果。

客户 告了加载项目级漏洞 告和导出时的错误。

容器扫描-允许列表的用法和逻辑。

无法在非最终MR上获得安全 告信息错误。

第一次单击时未禁用“触发手动操作”按钮，可能会发生多个API请求。

在管道列表中，状态标签使表格列溢出。

作业工件UI区域显示一条消息，用于在没有工件时下载工件。

地理辅助身份验证重定向到主站点的内部URL。

当Gitaly关闭时，Geo项目/Wiki同步不会显示任何错误。

更新Elasticsearch URL不会创建所有Elasticsearch索引。

发送从服务台创建的新问题的通知。

如果快速行动没有效果，提供更好的反馈。

测试用例的任务列表项被禁用。

在最后一行时，表情符 有可能被切断的bug。

在测试集成时捕获 络错误。

修正Jekins URL不能为空的问题。

VSA路径导航中如果缺少stage时间时候重复添加的问题。

CE版本MR时候卡在“此合并请求的管道未完成”中。

并行模式下的断字可能会使审阅者混淆的问题。

在树状视图中看不到最后一个文件。

在GitLab Web GUI中从名称较长的分支切换到名称较短的分支时，URL断开了的问题。

安全和合规性审计

合规管道配置 （ULTIMATE）

新版本中可以定义可强制执行的管道，该管道将在分配了在任何项目中运行合规性框架。

对于希望在管道工作流程中实现合规性要求的团队，可以通过为特定的合规性框架设置单个管道定义来实施更大的职责分离。使用该框架的所有项目将自动包含预定义的管道。用户可以扩展但不能修改下游项目中的管道配置，从而确保每次都以相同的方式运行合规性步骤。

为合规性框架定义合规性管道配置是确保组织始终如一地满足其法规要求，同时节省每个人的时间并鼓励安全/合规性与开发团队之间进行协作的好方法。

对Python，JS和TS的实验性Semgrep分析器

Gitlab和Semgrep紧密合作，推动GitLab SAST的未来发展，GitLab寻求Beta测试人员对Python，JavaScript和TypeScript的新型Semgrep分析器进行内测。这些实验性分析器与现有的Python，JavaScript和TypeScript分析器一起运行，因此可以比较各种分析器之间检测到的漏洞。

新的适用于Python的Semgrep分析器最终将取代现有的Python分析器Bandit。

JavaScript和TypeScript的新型Semgrep分析器最终将取代ESLint分析器。要运行这些分析仪中的任何一个，都需要在“ gitlab-ci.yml”配置文件中启用实验性SAST标志，以允许新的Semgrep分析仪与任何现有的SAST分析仪一起运行。

注意，目前尚未完成分析器之间的漏洞发现的重新映射，因此可能会在安全 告中看到重复的发现。在完成此过渡后，将解决此问题。

创建自定义合规性框架标签 （PREMIUM及以上）

GitLab当前提供了几个预定义的合规性框架标签，例如GDPR，HIPAA，PCI-DSS，SOC2和SOX。 在此版本中，可以添加自己的自定义框架，用户可以为自己的特定框架和流程自定义标签。 将来，将能够基于该标签创建可应用于项目的策略。

GitLab + Semgrep

GitLab SAST历来由十几个开源静态分析安全分析器提供支持。这些分析仪每月为使用GitLab的开发人员主动识别数百万个漏洞。这些分析仪中的每一个都是特定于语言的，并且具有不同的扫描技术方法。这些差异产生了用于更新，管理和维护开销其他功能的我们在这些工具之上构建的，并且给尝试进行调试的任何人造成混乱。

GitLab静态分析团队正在不断评估新的安全分析器。r2c开发团队的一个的相对较新的工具Semgrep是新的选择。Semgrep是一个快速，开放源代码的静态分析工具，用于查找错误并强制执行代码标准。Semgrep的规则看起来就像要搜索的代码；可以无需了解抽象语法树（AST）或正则表达式就编写自己的规则。

Semgrep灵活的规则语法非常适合简化GitLab的“自定义规则集”功能，以扩展和修改检测规则，这是GitLab SAST客户的普遍要求。Semgrep还拥有一个不断发展的开放源代码注册表，其中包含1000多个 区规则 。

gitlab正在将许多linte基础的SAST分析仪迁移到Semgrep。 该迁移有助于提高稳定性，性能，规则覆盖范围，并使GitLab客户能够访问Semgrep的 区规则以及我们将在未来添加的其他自定义规则集功能。

使用发行版CLI时支持自定义CA证书

在此之前，如果使用的是自建的GitLab实例，则需要CLI 与公共证书一起使用，不能集成自定义证书。在GitLab 13.11中，通过新增参数添加了对自定义证书颁发机构（CA）证书的支持：

ADDITIONAL_CA_CERT_BUNDLE 环境变量或
–additional-ca-cert-bundle标志。

除此之外还添加了INSECURE_HTTPS 环境变量和 –insecure-https标记，以便客户端可以跳过对服务器证书的验证，方式由于自签名SSL证书导致的失败。

从GitLab用户界面请求CVE ID

GitLab相信以负责任的态度披露软件漏洞。自2020年初以来，GitLab一直担任 CVE编 颁发机构（CNA ），可以为GitLab本身或GitLab SaaS上提供CVE ID托管的任何项目的安全研究人员和信息技术供应商。

在GitLab 13.11中，项目维护人员更容易通过UI从GitLab请求CVE ID 。关于在GitLab SaaS上托管的公共项目中的机密性问题，维护人员将能够在右侧边栏中请求CVE ID。单击问题侧栏中的“请求CVE ID”按钮，将转到GitLab CVE项目的新问题页面，可以在其中完成请求模板并触发请求工作流程。

如果项目所有者不希望其存储库向维护人员提供此功能，则也可以在项目设置页面上禁用此功能。 目前正在将此功能缓慢地在GitLab SaaS托管的项目推广。

管理员凭证清单中可用的GPG密钥（ULTIMATE）

现在，可以在管理区域中查看用户的GPG密钥信息。可以快速查看GitLab中存储了哪些密钥，及其ID，以及是否进行了验证，以帮助更好地了解用户如何与您的GitLab实例进行交互。