按照惯例GitLab发布有一个新的月度版本13.4.，本次发布主要带来了Vault for CI变量，Kubernetes Agent和Security Center能功能帮助团队降低风险，提高效率并加快交付速度，并提升到安全性，降低漏洞，提高效率，使用户体验更好，并帮助的团队更快地部署等。请追随虫虫一起来学习一下GitLab 13.4带来的新的功能。
本月的发行版为GitLab DevSecOps套件增加了一些功能。首先，作为构建和部署过程的一部分，现在可以将存储在HashiCorp Vault中的机密注入CI/CD作业中。
代码部署职责分开的组织可以通过Reporter访问Deployer角色来提升特定用户。部署者角色遵循最小特权访问的原则，允许他们批准合并请求并将代码部署到受保护的环境，而无需访问修改代码本身。
降低风险的另一种方法是使用新的GitLab Kubernetes代理。运营商可以从GitLab部署到其Kubernetes群集，而无需将其群集打开到整个网络。GitLab托管Terraform状态的新Terraform状态文件引入自动版本控制支持，以支持合规性和调试需求。最后但并非最不重要的一点是，"实例安全性"仪表板已演变为具有漏洞报告和设置功能的GitLab安全中心。
通过从搜索栏进行快速导航来快速跳转到最近的问题，组，项目，设置和帮助主题，从而改进了全局搜索功能。对于GitLab页面重定向，能够重定向站点中的各个页面和目录，这使用户能够更高效地部署页面站点。
对于那些希望获得增强的部署信息的人，新版本使可以从环境仪表板管理数百个受支持的项目部署。
长期以来，GitLab的Kubernetes集成使无需手动设置即可部署到Kubernetes集群。许多用户都喜欢易用性，而其他用户则遇到了一些挑战。当前的集成要求集群对Internet开放，供GitLab访问。对于许多组织来说，这是不可能的，因为他们必须出于安全性，合规性或监管目的而锁定群集访问。
最新的GitLab版本中发布了GitLab Kubernetes代理：一种部署到Kubernetes集群的新方法。
该代理在集群内部运行，无需将其打开到网络。代理通过从GitLab提取新更改来协调部署，而不是GitLab将更新推送到集群。无论使用哪种GitOps方法，GitLab都可以满足的要求。
注意，这这次发布是代理的第一个版本。当前，GitLab Kubernetes代理具有配置驱动的设置，并可以通过代码进行部署管理。尽管不支持某些现有的Kubernetes集成功能，例如Deploy Boards和GitLab Managed Apps，将在未来迭代中最终实现这些功能，并与代理提供注重安全性和合规性的集成。
GitLab 11.4中引入了功能标记。在12.2中，GitLab引入了百分比推广和用户ID功能标记策略。在13.1中，引入了功能标记用户列表，并支持每个环境多个功能标记策略。
今年早些时候，GitLab承诺将18个功能免费发布到CE产品中。在该版本的已经完成了将功能标志移动到Starter的工作，并且继续将功能标志服务迁移，在GitLab 13.5中在Core免费发布。
在GitLab上浏览时，有时只想转到特定项目而不是搜索结果页面。
使用全局搜索栏，在新版本中可以快速跳转到最近的问题，组，项目，设置和帮助主题。甚至还可以使用/键盘快捷键将光标移至搜索栏，从而更有效地导航。
在查看合并请求时，很难确定修改后的代码是否包含在单元测试中。审阅者可以改为依赖总体覆盖范围值，并要求在批准合并请求之前增加该值。这可能会导致开发人员采用分散的测试编写方法，但实际上可能无法提高代码质量或覆盖范围。
现在，开发人员在进行审阅时将在合并请求差异中看到代码覆盖率的可视化表示。该可视指示器可以轻松查看修改后的代码是否包含在单元测试中，从而有助于加快代码审阅以及合并和部署功能的时间。
从GitLab 12.5开始，使用环境面板只能在3个项目中看到7个环境。通过对仪表板进行分页来帮助大规模支持和管理环境，新改的GitLab 13.4中的环境仪表板，可以在项目中看到更多环境。
最近已经获得了GitLab Terraform提供程序的维护者权利，并计划在即将发布的版本中对其进行增强。在过去的一个月中，GitLab合并了21个请求请求并关闭了31个问题，其中包括一些长期未解决的错误和缺少的功能（如支持实例集群）。可以在Terraform文档中阅读有关GitLab Terraform提供程序的更多信息。
API模糊测试是在Web应用程序和API中查找其他扫描程序和测试技术所缺少的错误和漏洞的好方法。
GitLab的API模糊测试可让提供OpenAPI v2规范或应用程序的HAR文件，然后自动生成旨在解决极端情况并查找错误的随机输入。然后，结果立即显示为管道的一部分。
这是API模糊测试的第一个版本，后续将会持续改。
在GitLab指标仪表板中创建图表具有挑战性。在仪表板YAML文件中定义了图表之后，在master不知道新创建的图表就是想要的内容的情况下，会误提交更改了。
从GitLab 13.3开始，可以在创建图表时预览面板的YAML，从而在将更改提交到仪表板的YAML文件之前获得早期反馈。
当的团队管理多个GitLab项目时，应该能够轻松地看到一个数据点，该数据点显示了所有项目中代码覆盖率随时间的变化趋势。以前，可视化此趋势涉及繁琐的手动操作，需要从每个项目中下载覆盖率数据并将其插入电子表格中。
现在，以团队负责人的身份，可以快速轻松地收集每个小组项目或选定项目中可用的所有代码覆盖率数据作为.csv文件。这是一项MVC功能，随后将可以绘制随时间变化的平均覆盖范围。
此版本在覆盖率指导的模糊测试中引入了对多种新语言的支持。
现在，可以对以Java，Rust和Swift编写的应用程序进行模糊测试的所有功能，以发现其他进程遗漏的错误和安全漏洞！
环境页面显示了环境的一般状态。在此版本中，通过添加告警改进了环境页面。在环境状态旁边看到触发的告警，可以立即采取措施进行补救。
使用父/子管道时，子管道现在可以触发自己的子管道。当希望灵活地生成可变数量的子管道时，这种增加的深度可能很有用。
在使用父/子配置之前，每个子管道都需要在父中手动定义的触发作业。现在，可以生成动态触发任意数量的新子管道的子管道。例如，如果有monorepo，则可以根据分支中的更改动态生成第一个子管道，该子管道本身会生成可变数量的新子管道。
在父管道和子管道之间进行导航比较麻烦，需要多次单击。区分哪个作业触发了哪个子管道也不容易。现在，可以更轻松快捷地查看父管道与子管道的连接方式。
如果使用矩阵作业，可能会注意到很难确定每个作业使用的矩阵变量，因为作业名称的格式类似于matrix 1/4。在13.4中，现在将看到在该作业中使用的相关变量值，而不是看到通用作业名称。例如，如果要构建x86体系结构的调试目标，则该作业现在将命名为matrix: debug x86。
GitLab用户现在可以将其GitLab帐户连接到其Atlassian Cloud帐户。连接帐户允许用户使用其Atlassian凭据登录GitLab。此更改也为将来增强Gitlab Jira集成以及与Atlassian套件中的其他产品集成奠定了基础。
几个月前，GitLab宣布了开放18种功能的计划。为了兑现这一承诺，Core中现在提供了相关问题，问题CSV导出和问题委员会重点模式。这仅适用于"关联"关系。"阻止"和"被阻止"保留在付费层中。
在查看代码更改，讨论和合并请求中的提交时，通常需要在本地检出分支以进行更深入的查看。但是，随着更多滚动内容的出现，随着更多内容添加到合并请求描述中，查找分支名称变得更加困难。
现在已将分支名称添加到合并请求侧栏中，从而使其可以随时轻松访问，并且无需滚动。就像合并请求参考一样，源分支部分提供了一个方便的"复制"按钮，可以方便地进行本地检出。
将更改应用于多个文件的合并请求有时会折叠大文件差异，以提高性能。发生这种情况时，很容易忽略文件而不查看它，尤其是在合并具有多个文件的请求中。从GitLab 13.4开始，合并请求将强调包含折叠文件的差异，这将确保在代码审阅过程中审阅者不会丢失这些文件。
GitLab中的有效沟通取决于待办事项列表。如果在评论中被提及，那么能够遵循待办事项并采取行动或将其标记为已完成至关重要。当需要记住做某事或稍后再回来时，能够自己做事也很重要。
直到现在，都无法在设计上添加待办事项或将其标记为已完成，这令人非常沮丧。这确实削弱了产品团队之间的沟通效率，因为待办事项对于在GitLab中管理工作流程至关重要。
从13.4版开始，设计可以与问题注释保持一致，并且可以使用待办事项以获得更加一致和有用的体验！
在合并请求diff上折叠大文件是为了增强合并请求中diff部分的性能和响应能力。但是，在代码检查期间，由于滚动了大文件，检查者在滚动文件列表时可能会丢失某些文件。
合并请求差异页面的顶部引入了可见警告，明确告知用户该部分中的文件已折叠。这样可以确保对合并请求中的所有相关更改进行审核。
新改进了GitLab CI CD故障排除指南，其中包含有关可能遇到的常见问题的其他信息。希望改进后的文档是宝贵的资源，可帮助使GitLab CI/CD轻松快速地启动并运行。
以前，合并请求可能会因后期评论而意外地从合并中删除。如果合并请求已经在合并火车上，并且有人添加了一个注释，该注释创建了一个新的未解决的线程，则该合并请求被认为是不可合并的，并从火车上删除了。现在，在将合并请求添加到之后，可以进行新注释，而无需担心破坏合并过程。
作为开发人员，即使在复杂的情况下（例如，管道中有多个要解析的工作来计算覆盖率值的情况），也应该能够在管道完成运行后轻松查看代码覆盖率。到目前为止，"合并请求"窗口小部件仅显示这些值的平均值，这意味着必须导航到作业页面，然后返回到"合并请求"本身以获取有关覆盖范围值的更详细的详细信息。为了节省的时间并消除这些额外的步骤，现在向介绍平均覆盖率值，它与目标分支和源分支的关系以及工具提示，该提示显示用于计算平均值的每个作业的覆盖率。
GitLab软件包注册表是存储和共享各种软件包格式的地方。当项目或组中有大量软件包时，希望快速识别未使用的软件包并将其删除，以防止人们安装错误的软件包。可以使用Packages API或Package Registry用户界面从注册表中删除软件包。但是，直到最近，仍无法在UI中查看组时删除软件包。
现在，可以在查看组的程序包注册表时删除程序包。只需导航到组的Package Registry，按软件包名称过滤，然后删除所有不需要的软件包。
可以使用GitLab Conan存储库发布和共享C/C++依赖项。但是，程序包以前只能限于实例。这是有问题的，因为Conan软件包名称必须少于或等于51个字符。对于任何试图发布位于小组之内的软件包的人，gitlab-org/ci-cd/package-stage/feature-testing/conan使用该功能几乎是不可能的。
现在，可以将Conan软件包的作用域限定为一个项目，从而可以轻松发布和共享项目的依赖项。
当审阅者将合并请求（MR）设置为管道成功合并（MWPS）时，不会发送电子邮件通知。MR合并后，必须手动检查以查看状态或等待通知。在此版本中，通过在审阅者将MR设置为MWPS时自动通知合并请求线程中的所有订阅者来解决此问题。
GitLab用户现在可以选择要在EKS上配置的首选Kubernetes版本。与EKS上支持的Kubernetes版本保持一致，用户可以在1.14-1.17版本之间进行选择。
并非所有出现的问题都会首先触发告警：客户报告故障，团队成员确定性能问题。现在，事件是一种问题，因此团队成员可以通过熟悉的工作流程快速创建事件。在GitLab中的任意位置单击"新问题"，然后在"类型"字段中选择"事件"。
在GitLab风格的Markdown中添加了特定于告警的参考，从而改进了告警，使可以轻松共享和参考告警。用于^alert#1234在事件，问题或合并请求中的任何Markdown字段中引用告警。此告警参考还可以帮助确定告警产生的待办事项，而不是问题或合并请求。
告警的有效负载包含诊断故障和恢复服务的关键信息，并且该信息必须易于访问，因此在解决事件时无需切换工具或选项卡。通过告警创建的事件会在"告警详细信息"选项卡中显示告警的全部有效负载。
在GitLab 13.4中，当仅限于特定的名称空间和项目时，高级搜索现在将结果输出速度提高75%。
12.6中引入了延迟项目删除的功能。但是，以前没有办法将所有待删除的项目集中在一处。现在，自建实例的管理员可以在单个视图中查看所有待删除项目，以及可以轻松还原这些项目的按钮。
此功能使自建实例的管理员可以通过在单个位置汇总此信息并提供撤消不希望的删除活动的机会来更好地控制项目删除。
以前，只能通过GitLab UI分别访问每个组并应用这些规则来配置组推送规则。现在，可以通过API管理这些规则，以支持自定义的GitLab工具和自动化。
在GitLab 13.4中，新引入了一种配置静态站点编辑器的新方法。尽管配置文件在此版本中不存储或检索任何值，但为自定义编辑器行为奠定了基础。
在即将发布的版本中，将为添加值，.gitlab/static-site-editor.yml以设置网站的基本URL，从编辑器上传的图像的存储位置，覆盖Markdown语法首选项和其他特定于编辑器的设置。
前端问题是一种灵活方便的方法，可以在旨在由静态站点生成器解析的数据文件中定义特定于页面的变量。它通常用于设置页面的标题，布局模板或作者，但是当页面呈现为HTML时可以用于将任何类型的元数据传递给生成器。每个数据文件的最顶部都包含前端内容，通常将其格式化为YAML或JSON，并且需要一致且准确的语法。不熟悉特定语法规则的协作者可能会无意中引入无效的标记，从而可能导致格式问题甚至构建失败。
静态站点编辑器的WYSIWYG编辑模式已经从编辑器中删除了前端内容，以防止出现这些格式错误。
在GitLab 13.4中，可以在一个熟悉的基于表单的界面中访问和编辑每个前沿问题字段的值。单击"设置"按钮将显示一个面板，该面板显示定义的每个键的表单字段。使用当前值填充字段，编辑其中的任何一个就像在Web表单中键入一样简单。以这种方式编辑主题，可以避免语法复杂性，并可以完全控制内容，同时确保最终输出的格式一致。
对于Jira GitLab的用户，GitLab for Jira应用程序和DVCS Connector 允许显示有关GitLab提交的信息并直接在Jira中合并请求。结合与Jira的本地集成，可以在工作时轻松地在两个应用程序之间来回移动。
依靠人们以JSON或YAML格式编写配置的项目可能会引起问题，因为很容易打错字并弄乱事情。可以编写在CI管道中捕获此验证工具，但是使用JSON模式文件有助于提供文档和提示。
项目贡献者可以.gitlab/.gitlab-webide.yml在其存储库中的文件中定义自定义架构路径，该路径指定要验证的文件的架构和路径。在Web IDE中加载定义的文件时，将显示其他反馈和验证，以帮助创建文件。
如果使用的是有向非循环图（DAG）管道，则可能会发现一个作业可以列出的10个作业的限制needs:是不够的。在13.4中，默认限制从10增加到50，以允许管道中的作业之间的关系网络更加复杂。
在某些情况下，对于needs依赖项，管道中跳过的作业有可能被认为是成功的，这允许以后的作业本来可以运行。此问题已在13.4中修复，并且可以正确处理跳过的作业的行为needs。
GitLab现在将自动在任何活动分支，MR或标签上锁定成功作业和管道的最新工件，以防止其根据过期时间被删除。这使设置更激进的到期策略来清除较旧的工件变得更容易，有助于减少磁盘空间消耗，并确保始终从管道中获得最新工件的副本。
优化的CI / CD管道运行可以提高速度并节省成本。通过简短指南来改进文档，以便充分利用优化管道的优势。
单元测试报告是看到从管道的所有测试结果的简单方法。但是，如果有大量测试，则查找失败的测试可能很耗时。导致报表难以使用的其他问题包括难以滚动长的跟踪输出，并且对于少于1秒的测试，数据通常四舍五入为0。现在，默认情况下，"测试报告"首先将失败的测试排在报告的顶部，然后再按持续时间排序。这使查找故障和长时间运行的测试变得更加容易。而且，测试的持续时间现在以毫秒或秒为单位显示，因此读取速度更快，并且以前的滚动问题也已解决。
现在存在一些限制，这些限制限制了可以上传到GitLab软件包注册表的软件包文件的大小。添加限制是为了防止滥用并优化Package Registry的性能。限制因包装格式而异。对于GitLab在线仓，最大文件大小为：
· Canon：250MB
· Maven：3GB
· NPM：300MB
· NuGet：250MB
· PyPI：3GB
对于自建实例，默认设置相同。但是，管理员可以使用Rails控制台更新限制。
可以在源代码和CI/CD管道旁边使用GitLab PyPI存储库来构建，发布和共享python软件包。但是，以前无法通过使用预定义的环境变量来对存储库进行身份验证CI_JOB_TOKEN。结果，被迫使用个人凭据来更新PyPI存储库，或者可能决定完全不使用存储库。
现在，使用GitLab CI/CD通过预定义的CI_JOB_TOKEN环境变量来发布和安装PyPI软件包比以往更加容易。
对于GitLab Pages的用户，希望更好地管理URL更改，则会遇到无法在GitLab Pages站点中管理重定向的痛苦。现在，GitLab允许通过将配置文件添加到存储库来配置规则，以将Pages站点的一个URL转发到另一个URL。
对于合规性和偶尔的调试需求，必须具有访问Terraform状态的先前版本的权限。从GitLab 13.4开始提供对GitLab受管Terraform状态的版本控制。新的Terraform状态文件的版本控制会自动打开。现有的GitLab托管Terraform状态文件将在以后的版本中自动迁移到版本存储。
在对事件进行分类时，应该很容易确定告警已打开多长时间以及事件已触发了多少次。这些细节通常在确定客户影响以及团队现在需要做出响应时至关重要。在新的事件突出显示栏中，显示了告警的开始时间，事件计数，以及指向原始告警前端和中心的链接。此信息可用于告警引发的事件。
事件的严重性告诉响应者和利益相关者中断的影响以及响应所需的方法和紧迫性。当团队在故障处理过程中共享发现并补救中断时，可以编辑事件的严重性。现在，可以在"事件详细信息"页面的右侧边栏中编辑事件的严重性，严重性将显示在事件列表中。
容器网络策略编辑器的这一改进使用户可以直接在GitLab UI中轻松创建，编辑和删除其策略。该编辑器的功能包括.yaml为经验丰富的用户提供的模式和为不熟悉网络策略的用户提供的直观规则编辑器UI。可以在"安全性和合规性">"威胁管理">"策略"中找到新的策略管理功能。
GitLab和GitLab Runner现在都支持Azure Blob存储，这使得在Azure上运行GitLab服务变得更加容易。
GitLab实例支持所有对象存储类型的Azure，包括：LFS文件，CI工件，备份等。若要配置Azure Blob存储，请按照Omnibus或Helm Chart安装的说明进行操作。
GitLab Runners还支持Azure来存储分布式缓存。可以使用该[runners.cache.azure]部分配置Azure存储。
为了响应对在64位ARM架构上运行GitLab的支持的需求不断增长，很高兴地宣布正式提供ARM64 Ubuntu 20.04 Omnibus软件包。要下载并安装Ubuntu 20.04软件包，转"安装"页面并选择Ubuntu。
如今，实例级别的漏洞管理经验在功能和灵活性上都受到限制。当前的经验是一个页面，其中结合了漏洞详细信息，指标可视化和配置。没有足够的空间来扩展这些功能或利用其他安全功能。
对GitLab中的安全可见性和管理进行了根本性的更改。实例安全仪表板已转换为安全中心。最大的变化是引入了新的菜单结构。现在，可以找到一个"安全仪表板"，"漏洞报告"和"设置"区域，而不是单个页面。尽管功能没有改变，但将其分解可以实现将来的增强，否则这些增强将是困难的。这还将创建一个顶层框架，以在将来包含其他与安全性相关的功能。
专用的漏洞报告现在具有更多空间来显示重要详细信息，并继承了当前在项目漏洞列表中找到的详细信息。将漏洞度量小部件分隔到各自的区域中可以创建一个真正的安全仪表板。现在，它是用于将来的可视化的专用画布，不仅用于管理漏洞，而且还用于与安全相关的任何指标。最后，将"设置"拆分为自己的区域可为"漏洞管理"之外的实例级安全配置创建新的共享空间。
注重合规性的组织需要一种方法来向审核员展示与生产中任何特定更改有关的组件的整体视图。在GitLab中，这意味着连接所有点：MR，问题，管道，安全扫描以及其他有关提交的数据。到现在为止，必须挖掘GitLab应用程序和/或构建自定义工具来汇总信息-这不是很有效。
现在，可以以编程方式收集和导出此数据以满足审核要求，或者通过导航到"合规性仪表板"并单击按钮以导出该组的所有合并提交的列表来执行其他分析。生成的文件将包含所有合并提交及其作者，相关的合并请求ID，组，项目，批准者等。
管理对GitLab名称空间的访问是合规性计划的重要组成部分。从最小特权的原则到及时终止访问，GitLab中有一些与个人访问令牌相关的合规性要求。为了在命名空间中支持对这些用户凭据的更轻松，更好，更批量的管理，新引入了列出所有用户PAT并可以选择通过API撤消它们的功能。
对GitLab API功能的这些改进使用户可以列出和撤消其自己的PAT，并使管理员可以列出和撤消其用户的PAT。管理员现在可以更好地了解谁有权访问其名称空间，可以对用户的凭据做出数据明智的决定，并有权撤销可能已遭到破坏或可能超出公司的证书轮换政策的PAT。
如果团队需要在拥有开发的团队成员和拥有部署的团队成员之间保持职责分离，则GitLab中的权限范式使这一挑战变得棘手。
在GitLab 13.4中，可以授予非代码贡献者权限以批准合并请求进行部署，并实际部署代码，而无需授予他们维护者访问权限。
在GitLab 12.10中，GitLab引入了GitLab Runner的功能，以获取机密并将其注入CI作业。GitLab现在通过在文件中构建新语法来扩展JWT Vault身份验证方法。这使可以更轻松地在GitLab上配置和使用HashiCorp Vault。
将使用NuGet 4.9+或Conan软件包管理器的C，C ++，C＃和.Net项目的依赖项扫描添加到GitLab支持的语言和框架中。作为安全阶段的一部分，可以启用依赖项扫描来检查程序包管理器中包含的依赖项是否存在已知漏洞。这些漏洞及其严重性级别将显示在合并请求中，因此可以在合并前了解新依赖项可能带来的风险。还可以将项目配置为对严重性为"严重"，"高"或"未知"的任何漏洞要求合并请求批准。
证书库存提供了洞察管理员需要管理用户访问凭据GitLab实例。随着注重合规性的组织在凭据管理策略的严格性方面的差异，新添加了一个按钮，管理员可以选择撤消用户的个人访问令牌（PAT）。管理员现在可以轻松撤消可能已遭到破坏的PAT。此功能为需要更灵活的实施选项的组织提供支持，以最大程度地减少对用户的干扰。
除了最新发行版中引入的DAST按需扫描外，DAST扫描器配置文件还允许快速创建多个配置文件，以涵盖多种扫描类型，从而扩展了这些扫描的配置选项。在13.4中，"扫描程序配置文件"最初包括"蜘蛛超时"选项，该选项设置DAST蜘蛛在尝试发现要扫描站点的所有页面时应运行多长时间。它还包含一个目标超时选项，用于设置扫描器在站点未响应200或300状态码的情况下，应等待多长时间才能中止扫描。在后续版本中继续迭代此功能，更多配置选项将添加到"扫描仪配置文件"中。
当主要的Gitaly Cluster节点脱机时，该节点上的存储库被标记为只读，以防止在未复制的更改发生时丢失数据。如果节点重新联机，则GitLab不会自动恢复，管理员必须手动触发，否则，必须接受数据丢失。其他情况也可能导致存储库过时或只读，例如无法在辅助节点上处理复制作业。在这种情况下，存储库将保持过期，直到再次进行写入并触发复制作业为止。
为了解决这些情况，Praefect现在计划在一个节点上检测到过时的存储库但在另一节点上检测到存储库的最新版本时安排复制作业。此复制作业会自动将过期的存储库更新为最新状态，从而减轻了对手动数据恢复的担忧。自动修复还可以确保在复制作业失败时快速将辅助节点恢复到最新状态，而不必等待下一次写入发生。由于许多Gitaly群集存储大量存储库，因此这大大减少了管理员和站点可靠性工程师在故障转移后需要花费时间来恢复数据的时间。
此外，自动修复启动将存储库复制到添加到群集的任何新Gitaly节点的功能，从而在添加新节点时无需手动干预。
Gitaly Cluster允许在多个热Gitaly节点上复制Git存储库。通过消除单点故障来提高容错能力。在GitLab 13.3中引入的参考事务导致更改被广播到集群中的所有Gitaly节点，但是只有与主节点一致投票的Gitaly节点才会将更改保存到磁盘。如果所有副本节点都不同意，则仅将一个更改副本保留到磁盘上，从而造成单点故障，直到异步复制完成。
多数表决支持通过要求多数节点在保留对磁盘的更改之前达成一致来提高容错能力。启用功能标志后，写入必须在多个节点上成功进行。异议节点通过异步复制自动地从形成仲裁的节点开始同步。
现已提供证书映像的RedHat通用基本映像（UBI）版本。以前，使用基于UBI映像的部署需要对证书容器使用非UBI映像。要使用此新映像部署GitLab，请global.certificates.image.tag=master-ubi8在values.yaml文件中指定。
Helm安装现在支持智能卡身份验证。
子图表已添加，用于部署和配置Praefect服务。Praefect允许跨Gitaly节点集群管理Git存储库的存储，以实现容错配置。
下载到Workhorse的存档文件的缓存已针对Helm图表安装被禁用。从Omnibus安装方法开始将存档缓存存储在本地磁盘上。在Kubernetes部署中，磁盘不会在Pod之间共享。存档会随着时间的推移而累积，因为无法清理存档文件。这可能会导致节点上磁盘使用率过多的问题。
现在可以在图表中启用内容安全策略（CSP），以帮助防止JavaScript跨站点脚本（XSS）攻击。
现在，可以使用诸如通用访问卡（CAC）之类的智能卡对通过Helm图表部署的GitLab实例进行身份验证。使用X.509证书针对本地数据库对智能卡进行身份验证。这使Helm图表与Omnibus部署中可用的智能卡支持相当。
现在支持在ARM64上部署GitLab。
此发行版包括PostgreSQL的次要版本更新，从11.7到11.9，以及从12.3到12.4。
GitLab 13.4包括Mattermost 5.26。此版本包括通过实验性的侧边栏增强功能对频道进行分类和重新排序的功能，通过"询问社区"链接从Mattermost社区获得帮助的功能，以及更多功能。它还包括安全更新。建议从早期版本升级。
还将发布GitLab Runner 13.4。GitLab Runner与GitLab CI/CD协同工作，GitLab CI/CD是GitLab附带的开源持续集成服务。新功能包括：
将存储在Hashicorp Vault服务器中的机密用于CI/CD作业变量；
将Azure Blob存储用于运行程序缓存；
添加userns_mode对Gitlab CI服务的支持；
允许覆盖Kubernetes执行者的Service容器资源；
允许覆盖Kubernetes执行器的Helper容器资源；
添加Kubernetes节点关联性设置。
修复：使用PowerShell时，文件类型变量具有字节顺序标记；
修复：Docker身份验证随机行为；
修复：Docker Windows Git克隆；
所有更改的列表都在GitLab Runner CHANGELOG中。
在每个版本中，GitLab将继续在改善性能方面取得重大进展。致力于提高每个GitLab实例的速度。
在GitLab 13.4中，在问题，项目，里程碑等方面提高性能。GitLab 13.4的一些改进包括：
修复具有N ^ 2个查询的软件包版本渲染结果；
在某些情况下，将"设置">"通知"的加载时间从60s减少到〜2s；
具有较大描述的合并请求不再超时；
改善Snowplow遥测性能；
修复一些N + 1 GraphQL查询；
地理位置：提高打包文件查询的性能。
变更日期：2020年9月22日
Debian Jessie和Raspbian Stretch在2020年6月结束支持，GitLab 13.4不提供支持。GitLab 13.3是这些发行版的最后一个受支持的版本。请访问"不推荐使用的操作系统"页面以获取更多信息。
变更日期：2021年1月22日
当前，GitLab支持针对应用程序日志的text/json/logstash日志格式和针对访问日志的text/json/combined。将删除logstash和组合格式，仅使用两个选项（文本（用于开发）和json）统一应用程序和访问日志的格式化程序。
变更日期：2021年1月22日
Container Registry支持日志hook，目前仅可用于电子邮件通知。
如今，基于日志条目的告警通常由单独的工具处理。此功能的实现与底层日志记录库紧密耦合，这是在不影响可用功能的情况下切换依赖关系的能力的限制。
为了简化注册表功能和配置，将删除对日志记录挂钩的支持。
变更日期：2021年1月22日
当前为Redis连接池公开的一些配置设置与基础Redis客户端绑定，并且在替代库中没有等效设置。在开始改进Redis集成（例如增加对Sentinel的支持）的过程中，决定开始着手以功能更丰富，支持更好的替代方法来替换当前的Redis客户端依赖项。为此，需要替换绑定到当前客户端库的当前Redis池配置设置。
计算删除redis.pool.maxidle和redis.pool.maxactive设置，并添加redis.pool.size（最大连接数），redis.pool.minidle（最小空闲连接数）和redis.pool.maxlifetime（可以重新使用连接的最大时间）。
变更日期：2021年1月22日
有些容器注册表功能已过时或不再使用（至少在GitLab上）。支持这些功能限制了清理代码库并减少第三方依赖项列表的能力。
本proxy部分允许将Container Registry设置为上游存储库的本地镜像。在用于GitLab部署的注册表环境中，这样做的用处不大，用户很可能会将其注册表部署与GitLab实例放在一起，而不是使用托管在单独基础架构（例如Docker Hub）上的注册表服务。
变更日期：2021年1月22日
Bugsnag是容器注册表支持的错误报告服务之一。据统计，没有一个用户依赖此服务，在GitLab 使用Sentry。为了简化和整合支持的错误报告服务，打算增加对Sentry的支持，并删除对Bugsnag的支持。
变更日期：2021年1月22日
NewRelic是容器注册表支持的错误报告服务之一。据统计，没有一个用户依赖此服务，打算添加对Sentry的支持，并删除对NewRelic的支持。
变更日期：2021年1月22日
GitLab将于2021年1月22日通过Docker注册表v1 API禁用拉取功能.Docker在2019年6月弃用，此功能使GitLab团队可以专注于针对当前注册表用例的功能和修复程序。
变更日期：2020年11月22日
CentOS 6将于2020年11月停止官方支持。GitLab 13.6将是在CentOS 6上部署GitLab的最后一个受支持版本。建议升级到CentOS 7或8。请访问不推荐使用的OS页面，以获取有关受支持发行版的更多信息。
变更日期：2020年9月22日
旧版功能标志将变为只读。它们仍然可以使用，但是不能仅通过API通过UI进行编辑。建议将的旧功能标记迁移到功能标记策略。为此，可以先对旧式标志进行截图以进行跟踪。然后通过API/UI删除该标志（无需更改代码），并创建一个与已删除的旧标志同名的新功能标志。另外，请确保策略和环境与已删除的标志匹配。
变更日期：2021年6月22日
在GitLab Runner 13.2中，PowerShell Core支持已添加到Shell执行程序中。在14.0中，pwsh它将是Windows上注册的跑步者的默认外壳。Windows Command Shell仍可作为Windows运行程序的选项使用。
变更日期：2021年6月22日
在GitLab转轮13.3，一个符号链接从加入/user/lib/gitlab-runner/gitlab-runner到/usr/bin/gitlab-runner。在14.0中，将删除此符号链接，并将GitLab Runner安装在中/usr/bin/gitlab-runner。
变更日期：2021年6月22日
在GitLab Runner 13.1，开始发送sigterm，然后再发送sigkill到Shell执行程序中的进程。还引入了一个新的功能标志，FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL它允许使用以前的过程终止方法。在GitLab Runner 14.0中，将删除功能标记。
变更日期：2021年6月22日
Ubuntu 19.10（Eoan Ermine）已于2020年7月17日星期五到期，在GitLab Runner 14.0中，将从软件包分发中删除Ubuntu 19.10。
变更日期：2021年6月22日
在GitLab Runner 13.0，为GitLab Docker Machine执行程序引入了新的配置设置计时选项。在GitLab Runner 14.0中，将删除旧的配置选项非高峰时间模式。
变更日期：2021年6月22日
在GitLab Runner 13.5中，介绍了failed并success声明了一项工作。为了支持Prometheus规则，选择了to success和failure to finished作为指标。在14.0中，将删除转换。有关更多详细信息，
变更日期：2021年6月22日
在GitLab Runner 13.2中，将step_script to 的翻译build_script添加到了自定义执行器。在14.0中，build_script舞台将替换为step_script。
通过Omnibus安装的自建实例可直接使用Linux包管理器可以升级。例如对CentOS:
yum updata/install gitlab-ce
就能自动完成升级：
先停止和删除旧的容器：
sudo docker stop gitlab
sudo docker rm gitlab然后Pull官方最新镜像：
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 pull
docker-compose up -d在GitLab 13.0中，旧存储已被弃用，旧存储中的所有项目将自动升级到GitLab 13.2中的新哈希存储。该迁移被延迟到GitLab 13.4。
升级到13.4后，仍在旧存储中的所有项目都将通过后台迁移自动迁移。
页面更新：2024-04-24
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号
