GitLab 17.0:通用CI/CD目录,基于Ansible脚本GET一键安装包
很多朋友对于GitLab 17.0:通用CI/CD目录,基于Ansible脚本GET一键安装包和不太懂,今天就由小编来为大家分享,希望可以帮助到大家,下面一起来看看吧!
包含组件和输入的CI/CD 目录现已公开
CI/CD 目录提供对社区和行业专家创建的大量组件的访问。无论您是在寻找持续集成、部署管道还是自动化任务的解决方案,都可以按类别浏览以查找适合您需求的组件。
价值流仪表板中的AI 影响分析(终极版)
AI Impact 是价值流仪表板中提供的仪表板,可帮助组织了解GitLab Duo 对生产力的影响。这个新的逐月指标视图将AI 使用趋势与SDLC 指标(例如交付时间、周期时间、DORA 和漏洞)进行比较。 PM 和其他经理可以使用AI Impact 仪表板来衡量端到端工作流程节省了多少时间,同时关注业务成果而不是开发人员活动。
在第一个版本中,AI 使用情况以每月代码建议使用情况来衡量,计算方式为每月唯一代码建议用户数除以每月唯一贡献者总数。
终极用户可以在有限的时间内使用AI影响仪表板。之后,需要GitLabDuo Enterprise 许可证才能使用仪表板。
Linux Arm 上托管的运行程序简介(高级版)
GitLab SaaS 提供Linux Arm 托管运行器。现在可用的中型和大型Arm 机器类型分别具有4 个或8 个vCPU,与GitLabCI/CD 完全集成,使得比以往更快、更经济高效地构建和测试应用程序成为可能
介绍部署详细信息页面(高级版)
在新版本中,您可以直接链接到GitLab中的部署。以前,如果您在部署上进行协作,则必须从部署列表中查找该部署。由于列出的部署数量众多,因此找到正确的部署非常困难且容易出错。
从17.0 开始,GitLab 提供了可以直接链接到的部署详细信息视图。在第一个版本中,部署详细信息页面提供了部署作业的概述以及在持续交付设置中批准、拒绝或评论部署的可能性。
GitLab Duo Chat 现在使用Anthropic Claude 3 Sonnet(高级版)
GitLab Duo Chat 变得更好了。新版本使用Anthropic Claude 3 Sonnet 作为基础模型,取代Claude 2.1 来回答大多数问题。
GitLab 在为一系列任务选择最佳模型并编写性能良好的提示时采用测试驱动的方法。通过最近对聊天提示的调整,与之前基于Claude 2.1 构建的聊天版本相比,基于Claude 3 Sonnet 的聊天答案在准确性、全面性和可读性方面有了显着提高。
GitLab Duo Chat 支持自中间实例中的操作方法问题(终极版)
GitLab Duo Chat 的一个流行功能是回答有关如何使用GitLab 的问题。虽然Chat 提供了各种其他功能,但此特定功能以前仅在GitLab SaaS 中可用。
新版本中还支持自建GitLab实例。新手和专家都可以通过Chat 寻求帮助来解决诸如“如何在GitLab 中更改密码?”之类的问题。或“如何将Kubernetes 集群连接到GitLab?”。聊天旨在提供有用的信息以更有效地解决问题。
价值流仪表板中的新使用情况概述面板(终极版)
带有概览面板的增强型价值流仪表板。新的可视化功能满足了执行管理层深入了解软件交付性能的需求,并清楚地展示了GitLab 在软件开发生命周期(SDLC) 中的使用。
概述面板显示组级别指标,例如(子)组、项目、用户、问题、合并请求和管道的数量。
将组添加到CI/CD 作业令牌白名单
GitLab 15.9 中引入的CI/CD 作业令牌允许列表可以防止其他项目未经授权访问您的项目。此前,只能在项目级别允许其他特定项目的访问,最多可达200 个项目。
在GitLab 17.0 中,可以将组添加到项目的CI/CD 作业令牌白名单中。支持最多200 个列表适用于项目和组,这意味着项目允许列表现在最多可以包含200 个具有授权访问权限的项目和组。此改进使得添加与组关联的大量项目变得更加容易。
CI/CD 添加关键字规则:exists 以增强上下文控制
CI/CD 关键字规则:exists 的默认行为根据定义关键字的位置而有所不同,这可能会使其更难以与更复杂的管道一起使用。在作业中定义时,rules:exists 会在运行管道的项目中搜索指定文件。但是,当在节包含中定义时,rules:exists 会在托管包含该节的配置文件的项目中搜索包含指定的文件。如果配置分散在多个文件和项目中,则可能很难知道将在哪个确切项目中搜索定义的文件。
在新版本中,引入了project和ref子键rules:exists,提供了一种显式控制该关键字的搜索上下文的方法。这些新子项可通过精确指定搜索上下文、减少不一致并提高管道规则定义的清晰度来帮助您确保准确的规则评估。
使用Switchboard (Ultimate) 进行配置更改的变更日志
在新版本中,您可以使用Switchboard 配置页面来查看对GitLab 私有实例基础设施所做的配置更改的状态。
所有有权在Switchboard 中查看或编辑租户的用户都将能够查看配置更改日志中的更改,并在这些更改应用于实例时跟踪这些更改的进度。
目前,交换机配置页面和更改日志可用于更改,例如通过将IP 添加到允许列表或配置实例的SAML 设置来管理对实例的访问。
GitLab 17.0 中的其他改进
使用REST API 查看GitLab 中的Jira 问题(高级版)
在此版本中,可以使用REST API 在GitLab 中查看Jira 问题。您还可以指定一个或多个Jira 项目来查看问题。
移民项目分类认定
新版本可以支持直接传输,在GitLab实例之间迁移GitLab组和项目。到目前为止,进口项目的识别并不容易。在新版本中,为通过直接传输导入的项目添加了视觉指示器,其中创建者被识别为特定用户:
评论(系统评论和用户评论)、问题、拉取请求、史诗、设计、片段和用户个人资料活动。
在GitLab 中查看多个Jira 项目的问题
对于较大的仓库,在新版本中,您可以在设置Jira 问题集成时在GitLab 中查看多个Jira 项目的问题,可以实现:
输入最多100 个Jira 项目密钥,以逗号分隔。
将Jira 项目密钥留空以包含所有可用密钥。
在GitLab 中查看Jira 问题时,您可以按项目过滤问题。
要为GitLab Ultimate 中的漏洞创建Jira 问题,您只能指定一个Jira 项目。
增强的Epic 删除保护(高级)
新版本的Take Care 更新了删除Epic 时发生的情况,以更好地保护项目的结构和数据。这是为了让您在管理项目时获得更多控制权并安心无忧。在新版本中,当删除父Epic时,其所有子记录不会自动删除,而是通过先分离父关系来保留它们。此更改提供了一种更安全的方式来管理Epic,确保意外删除不会导致有价值信息的丢失。
问题板上可见的里程碑和迭代
新版本中改进了问题板,以便更清晰地了解项目时间表和阶段。轻松跟踪进度并动态调整新版本中团队的工作量,并在问题卡上直接显示里程碑和迭代详细信息。此增强功能旨在提高您的计划和执行效率,让您随时了解情况并提前完成计划。
简化的价值流仪表板配置文件架构(终极版)
在新版本中,可以使用简化的架构驱动的可定制UI 框架来定制价值流面板。在新格式中,字段在显示数据和布局仪表板面板方面提供了更大的灵活性。借助新框架,管理员可以跟踪仪表板随时间的变化。版本历史记录可以帮助恢复到以前的版本并比较仪表板版本之间的更改。
使用这种定制,决策者可以专注于与其业务最相关的信息,而团队可以更好地组织和显示关键的DevSecOps 指标。
1JetBrains IDE 的GitLabDuo 插件中的密码集成(高级版)
在新版本中,1Password密码管理可以与JetBrains的GitLabDuo插件集成。开发人员可以在JetBrains IDE 设置中将个人访问令牌替换为1Password 密钥引用。这简化了密钥管理并实现无缝密钥轮换,而无需手动更新令牌。
签署GitLab UI 的提交
以前,无法对GitLab 进行的Web 提交和自动提交进行签名。在新版本中,您可以使用签名密钥、提交者姓名和电子邮件地址配置自建实例来签署Web 并自动提交。
总是after_script 对取消的作业运行命令
CI/CD 关键字after_script 用于在脚本作业的主要部分之后运行附加命令。这通常用于清理作业使用的环境或其他资源。但是,如果作业被取消,after_script 命令将不会运行。
从GitLab 17.0 开始,当作业被取消时,after_script 命令将始终运行。
已发布的CI/CD 组件的语义版本范围
使用CI/CD 目录组件时,您可能希望让它自动使用最新版本。例如,您不希望手动监控所有使用的组件并在每次有次要更新或安全补丁时手动切换到下一个版本。但使用~latest 也有一点风险,因为次要版本更新可能会产生不良行为更改,而主要版本更新则带来更高的破坏性更改风险。
在新版本中,您可以选择使用CI/CD 组件的最新主要或次要版本。例如,指定2 个组件版本,您将获得该主要版本的所有更新,例如2.1.1、2.1.2、2.2.0,但不是3.0.0。指定2.1 将仅获取该次要版本的补丁更新,例如2.1.1、2.1.2,但不获取2.2.0。
过滤包注册表UI 以查找有错误的包
可以使用GitLab 包注册表发布和下载包。有时,包会因错误而无法上传。之前无法快速查看上传失败的包。这使得获得组织的包注册表的完整视图变得困难。
在新版本中,可以过滤包注册表UI 以查找上传失败的包。此改进使调查和解决遇到的任何问题变得更加容易。
GitLab 代理支持FIPS 模式下的Kubernetes
从GitLab 17.0 开始,您可以在FIPS 模式下安装GitLab 并启用Kubernetes 组件的代理。在新版本中符合FIPS 的用户可以受益于Kubernetes 与GitLab 的所有集成。
服务台中有多个外部参与者
有时,不止一个人参与解决支持票证,或者请求者希望让同事了解票证的最新状态。在新版本中,最多10 名没有GitLab 帐户的外部参与者可以处理帮助台票证和一般问题。
对于工单上的每条公共评论,外部参与者都会收到一封帮助台通知电子邮件,他们的回复将在GitLab UI 中显示为评论
只需使用快速操作/add_email 和remove_email,通过几次按键即可添加或删除外部参与者。
GitLab 还可以配置为将初始电子邮件标头中的所有电子邮件地址添加到帮助台票证中。
所有帮助台电子邮件模板都可以使用Markdown、HTML 和动态占位符根据您的喜好进行自定义。取消订阅链接占位符使外部参与者可以轻松选择退出对话。
自动删除未经验证的辅助电子邮件地址
如果辅助电子邮件地址已添加到用户个人资料但未经验证,它将在三天后自动删除。此前,这些电子邮件地址处于保留状态,如果没有人工干预,则无法释放。这种自动删除功能可减少管理员开销,并防止用户保留不属于他们的电子邮件地址。
编辑自定义角色及其权限(终极)
以前,无法编辑现有的自定义角色及其权限。可以在新版本中编辑自定义角色及其权限,而无需重新创建角色来进行更改。
改进了管理员和组的分支保护设置(终极版)
以前,设置默认分支保护选项不允许与设置受保护分支相同级别的配置。
在此版本中,默认分支保护设置已更新,以提供与受保护分支相同的体验。这样可以更灵活地保护默认分支,并简化流程以匹配受保护分支设置中已有的内容。
将合并请求审批策略切换为“失败打开”或“失败关闭”(终极版)
对于许多组织来说,合规性是按浮动比例运作的,在满足要求和确保开发人员速度不受影响之间取得平衡。合并请求批准策略有助于在DevSecOps 工作流程的核心(合并请求)中实现安全性和合规性。正在引入失败开放合并请求批准策略的新选项,以便为希望在组织中推出控制措施时轻松过渡到策略实施的团队提供灵活性。
当合并请求审批策略配置为失败时,现在只有在违反策略规则并且项目具有正确配置的安全分析器时才会阻止MR。如果未为项目启用分析器或分析器未成功生成结果,则策略将不再认为这是给定规则和分析器的违规行为。这种方法允许在团队努力确保正确的扫描执行和实施时逐步推出策略。
Linux 软件包改进(高级)
CentOS Linux 7 将于2024 年6 月30 日停止支持。GitLab17.1 将是最后一个支持CentOS 7 的GitLab rpm 包。
私人共享组成员在所有成员的“成员”选项卡上列出
使用REST API 从Bitbucket 云导入
在新版本中,添加了使用REST API 导入Bitbucket Cloud 项目的功能。对于导入大量项目来说,这是比使用UI 导入更好的解决方案。
使用API 重新导入选定的项目关系
从包含许多相同类型项目(例如合并请求或管道)的导出文件导入项目时,有时某些项目不会导入。
在此版本中,添加了API 接口,用于重新导入命名关系,跳过已导入的项目。该API需要以下两项:
项目导出存档。
类型(问题、合并请求、管道或里程碑)。
设计管理能力扩展到产品团队
GitLab 正在通过更新的权限扩大协作。新版本中具有报告者角色的用户可以访问设计管理功能,使产品团队能够更直接地参与设计过程。这一变化通过邀请整个组织更广泛的参与来简化工作流程并加速创新。
团体客人可以链接问题(高级)
减少将问题和任务从报告者关联到访客所需的最低角色,从而在维护权限的同时更灵活地组织整个GitLab 实例的工作。
价值流仪表板中合并指标的新中位时间(终极版)
价值流仪表板中添加了一个新指标:合并中值时间。在GitLab 中,该指标表示合并请求创建时间和合并时间之间的中位时间。新指标通过确定合并请求和代码审查流程的效率和生产力来衡量DevOps 的健康状况。
通过分析此指标在其他SDLC 指标的背景下如何演变,团队可以识别生产力低或高的月份,了解新的DevOps 实践对开发速度和交付流程的影响,减少总体交付时间,并提高软件交付速度。
按创建日期、上次更新日期和标题对路线图进行排序(高级)
路线图视图中提供了扩展的Epic 排序选项,在组织项目和确定项目优先级时提供更大的灵活性。在新版本中,Epics 可以按照创建日期、上次更新日期和标题进行排序。此增强功能为未来更高级的排序功能奠定了基础,以帮助更动态地管理Epics。
使用可自定义的快捷方式更快地访问GitLabDuo 聊天(高级版)
在新版本中,直接从JetBrains 中的编辑器打开Duo Chat 更加容易。使用默认的Alt+D 键盘快捷键(或设置您自己的快捷键)快速打开Duo Chat 并输入问题。使用相同的键盘快捷键关闭窗口。
项目评审模板(高级)
在GitLab 16.11 中发布群组评论模板后,这些模板被引入到GitLab 17.0 项目中。
在整个组织中,在问题、史诗和合并请求中使用相同的模板化响应会很有帮助。这些回复可能包括要回答的标准问题、对常见问题的回复或结构良好的合并请求审核评论。项目级评论模板为您提供了另一种方式来确定模板的可用性范围,从而使组织在跨用户共享这些模板时具有更多的控制力和灵活性。
要创建评论模板,请转到GitLab 上的任何评论框,然后选择插入评论模板管理项目评论模板。创建评论模板后,所有项目成员都可以使用它。发表评论时选择插入评论模板图标,将应用保存的回复。
标准化CI/CD Catalog 组件发布流程
我们一直在努力开发CI/CD 组件,包括使将组件发布到CI/CD 目录的过程成为一致的体验。作为这项工作的一部分,使用关键字release和image从CI/CD作业发布版本已被实现为唯一的方法。对发布过程的所有改进仅适用于此方法。为了避免此限制引入重大更改,请确保始终使用最新版本的映像(release-cli:latest) 或至少高于v0.16 的版本。现在,对于CI/CD 组件项目,UI 中的“发布”选项已禁用。
增加Kubernetes 代理授权限制
使用GitLab Kubernetes 代理,可以与组共享单个代理连接。最终目标是支持大型多租户集群中的单个代理。以前,使用CI/CD 只能与100 个项目和组共享代理,使用user_access 关键字只能与100 个项目和组共享代理。在GitLab 17.0 中,可以共享的项目和组的数量增加到500 个。
跟踪部署中的快速合并请求
在过去的版本中,仅当项目的合并方法是合并提交或具有半线性历史记录的合并提交时,才会在部署中跟踪合并请求。从GitLab 17.0 开始,在部署中跟踪合并请求,包括合并方法为快进合并的项目。
为用户定制头像
现在可以使用API 上传任何用户类型的自定义头像,包括机器人用户。这对于在UI 中从视觉上区分机器人用户(例如组和项目访问令牌或服务帐户)与人类用户特别有用。
识别管理员模式发起的会话
作为实例管理员,当使用多个浏览器或不同的计算机时,可能很难知道哪些会话处于管理模式,哪些不是。在新版本中,管理员可以转到“用户设置”“活动会话”来确定哪些会话使用管理模式。
在自我管理实例级别管理自定义角色(终极版)
在此版本之前,在自建的GitLab 实例上,必须在组级别创建自定义角色。这可以防止管理员集中管理实例的自定义角色,从而导致整个实例中出现重复的角色。在新版本中,自定义角色在自创建实例级别进行管理。只有管理员可以创建自定义角色,但管理员和群组所有者都可以分配它们。
策略机器人评论可选配置(旗舰版)
当合并请求违反策略时,安全策略机器人会发布评论,帮助用户了解该策略何时在其项目上实施、何时完成评估以及是否存在任何阻止MR 的违规行为,并提供解决指导的问题。这些注释现在是可选的,可以根据策略启用或禁用。这为组织提供了灵活性和控制力,以确定他们希望如何向用户传达这些策略。
自定义角色的用户体验改进(终极版)
对自定义角色的用户体验进行了一系列改进,具体如下:
创建新的自定义角色时会打开一个新页面。
改进了自定义字符表的设计。
改进了删除自定义角色对话框的设计。
预先检查基本角色的权限。
成员页面显示受邀群组的成员
Beta版本提供两种数据库模式
目前大多数自建实例客户只使用单一数据库。为了保证GitLab SaaS和自建实例的设置一致,自建实例的客户需要默认迁移并运行分解。在16.0中,两个数据库连接成为自建实例安装的默认设置。 17.0 将会结束对自建实例单数据库连接的支持,但对单数据库两连接的支持将持续到19.0。
在17.0 中,两个数据库模式作为有限测试版发布,目标是在19.0 之前普遍可用运行分解。在17.0 中迁移仍然是可选的,但需要在升级到19.0 之前执行。
通过可自定义的语言设置获得更多代码建议
在GitLab VS Code 工作流程扩展中,现在可以选择为代码建议配置其他语言。该功能目前仍是一个实验项目。
亚搏体育appGitLab跑步者17.0
GitLab Runner 17.0 也同时发布。主要更新内容有:
有关在断开连接的环境中安装Runner Operator 的文档。
GitLab 图表改进
GitLab Operator 现在可用于云原生混合安装的生产使用。
global.busybox 删除了在指定自定义BusyBox 值时回退到BusyBox 图像的支持。
对基于BusyBox 的init 容器的支持已在GitLab 16.2 (Helm Chart 7.2) 中弃用,并由基于通用GitLab 的init 映像取代。
对gitlab.kas.privateApi.tls.enabled 和gitlab.kas.privateApi.tls.secretName 的支持也已被删除。必须改为使用Global.kas.tls.enabled 和global.kas.tls.secretName。
已弃用的队列选择器和否定选项已从Sidekiq 图表中删除。
安全与合规性
先科安全扫描器更新
从SAST CI/CD 模板中删除一组特定于语言的分析器,并将其覆盖范围替换为来自基于Semgrep 的分析器的GitLab 支持的检测规则。以下分析器现已弃用,并将在GitLab 17.0 中终止支持:
Brakeman(Ruby、Ruby on Rails)Flawfinder(C、C++)MobSF(Android、iOS)NodeJS 扫描(Node.js)PHPCS 安全审核(PHP)
更改SAST CI/CD 模板以停止基于SpotBugs 分析器的Kotlin 和Scala 代码。上述语言中SAST的分析功能将基于Semgrep使用GitLab支持的检测规则进行扫描。已弃用的分析器将仅收到安全更新;不保证其他一般改进或更新。 GitLab 17.0 结束对分析器的支持后,将不再提供进一步的更新。但是,默认情况下,GitLab 不会删除以前发布的这些分析器的容器映像,也不会删除使用自定义CI/CD 管道作业定义运行它们的能力。漏洞管理系统将更新大多数现有发现,以便它们符合新的检测规则。未迁移到新分析仪的结果将自动解决。
如果删除的分析器应用了自定义,或者基于Semgrep 的分析器当前在管道中被禁用,则您必须按照此更改的弃用问题中详细说明采取操作。
自定义角色的新权限(终极)
可以使用新权限创建自定义角色:
分配安全策略链接;
管理和分发合规框架;
管理网络钩子;
管理推送规则;
当这些自定义权限被释放后,您可以通过为这些所有者创建具有同等权限的自定义角色来减少组中所需的所有者数量。自定义角色允许您定义精细的角色,仅授予用户完成其工作所需的权限,并减少不必要的权限升级。
DAST 现在默认支持arm64 和amd64 架构(终极版)
DAST 5 默认支持arm64 和amd64 架构。这使客户能够选择Runner 托管架构并优化成本节省。
Android 依赖扫描支持(终极版)
依赖扫描的用户现在可以扫描Android 项目。要配置Android 扫描,请使用CI/CD 目录组件。 CI/CD 模板的用户还支持Android 扫描。
秘密检测在覆盖或禁用规则时支持远程规则集(终极版)
新版本中解决了影响远程规则集的秘密检测错误。可以通过远程规则集覆盖或禁用规则。远程规则集提供了一种可扩展的方式来在单个位置配置可跨多个项目应用的规则。
API 安全测试分析器更新(终极版)
在17.0 中,已发布以下API 安全测试分析器更新:
系统环境变量现在从CI 运行程序传递到用于某些高级场景(例如请求签名)的自定义Python 脚本。这将使这些场景的实现变得更加容易。
API 安全容器现在以非root 用户身份运行,从而提高了灵活性和合规性。
支持仅提供TLSv1.3 密码的服务器,使更多客户能够采用API 安全测试。
容器镜像升级至Alpine 3.19,解决了安全漏洞。
依赖扫描默认Python镜像(终极版)
在弃用Python 3.9 作为默认Python 映像后,Python 3.11 现在成为默认映像。
新的默认Python 版本面向3.10。为了确保FIPS 合规性,需要直接迁移到Python 3.11。
引入高级漏洞跟踪(终极版)以进行隐蔽检测
秘密检测现在使用先进的漏洞跟踪算法来更准确地识别同一秘密何时由于重构或不相关的更改而在文件中移动。如果出现
以下情况,则不再创建新发现: 泄漏在文件内移动。 同一文件中出现相同值的新泄漏。 否则,现有工作流程(合并请求小部件、管道报告和漏洞报告)将像以前一样处理结果。通过确保不会将重复的漏洞报告为秘密转移位置,团队可以更轻松地管理泄露的秘密。 更新了漏洞报告的过滤功能(Ultimate) 漏洞报告过滤器的旧实现不可扩展。受页面水平空间的限制。在新版本中可以使用过滤搜索组件按状态、严重性、工具或活动的任意组合过滤漏洞报告。此更改允许用户添加新的过滤器,例如此建议的按标识符过滤。 简化了SAST分析器的覆盖范围,涵盖更多语言 GitLab 静态应用程序安全测试 (SAST) 现在可以使用更少的分析器扫描相同的语言,从而提供更简单、更可定制的扫描体验。 在GitLab17.0 中,已将基于Semgrep的分析器中针对以下语言的特定语言分析器替换为GitLab管理的规则: 安卓、C和C++、iOS、Kotlin、Node.js、PHP,Ruby 新更新SASTCI/CD模板,以反映新的扫描覆盖范围,并删除不再使用的特定于语言的分析器作业。 错误修复、性能改进和UI改进 在17.0中提供的所有错误修复、性能增强和UI方面做了持续改进(详略)。 功能弃用和重大变化 在17.0有些功能被启用,有些有重要变化更新: GraphQL中删除“previousStageJobsOrNeeds”。 删除对不受支持的方法访问 GraphQL API的支持。 SAST安全扫描重大更新 从SAST CI/CD模板将删除对Brakeman (Ruby, Ruby on Rails)、Flawfinder (C, C++)、MobSF (Android, iOS)、NodeJS 扫描 (Node.js)、PHPCS安全审计 (PHP)等支持,并停止基于SpotBugs分析器的Kotlin和Scala代码分析。所有语言分析将都基于Semgrep的分析器中GitLab 支持的检测规则替换它们的覆盖范围。 升级更新 Linux package (原Omnibus GitLab)Omnibus Omnibus套件被新命名为Linux安装包,目前支持的发行版信息如下: 这些系统的自建实例可直接使用发行版本自带的包管理器可以升级。 例如对CentOS: yum updata/install gitlab-ce 就能自动完成升级。 GET脚本 在安装上GitLab新提供了GET(Gitlab Environment Toolkit)环境工具包,这是基于Terraform和Ansible脚本来用于帮助按照参考架构部署扩展的自管理GitLab环境。 GET工具包由GitLab质量工程支持团队创建和维护,支持以下功能: 支持动态部署从1k到50k的所有参考架构大小。 支持部署参考架构的云原生混合变体(目前仅限AWS和GCP)。 GCP、AWS和Azure(Linux包)云提供商支持。 nightly Linux 软件包(Omnibus)构建支持. 使用OpenSearch进行高级搜索. Geo支持; 容器注册表支持; 零停机升级支持; 内置可选负载平衡和监控(Prometheus)设置; SSL/TLS支持(直接或通过hooks); 本地支持 (Ansible); 自定义配置/任务/文件支持; ET工具包可以实现零停机升级,使用编辑好的zero_downtime_update.yml使用: ansible-playbook -i environments/10k/inventory playbooks/zero_downtime_update.yml Docker版本 先停止和删除旧的容器: sudo docker stop gitlabsudo 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 通过: docker-compose pull docker-compose up -d 升级到GitLab17.0的重要说明 在升级到GitLab17.0之前,如果使用Sentry跟踪GitLab环境中的错误,则必须将Sentry 实例升级到21.5.0或更高版本。 必须先升级到GitLab1 6.11,然后再升级到GitLab17.0,以完成后台迁移。
用户评论
"这款GitLab更新真是太方便了,一个通用CI/CD目录简直是开发者的福音!"
有13位网友表示赞同!
"一键安装包?这也太酷了吧!有了它,部署起来简直不要太快!"
有15位网友表示赞同!
"终于不用再手动配置CI/CD流程了,基于Ansible脚本的安装包真是太棒了!"
有13位网友表示赞同!
"以前总是花很长时间在安装和配置上,现在一键搞定真是让人心动。"
有11位网友表示赞同!
"这个通用目录听起来很有潜力,可以整合各种工具,提高开发效率!"
有5位网友表示赞同!
"期待进一步了解Ansible脚本的具体功能,是不是能更方便地管理部署过程?"
有19位网友表示赞同!
"这版本发布太棒了!这下终于可以在GitLab上完成整个CI/CD流程。"
有13位网友表示赞同!
"这么实用的功能难道不是应该早点上线的吗?看来我得尽快升级GitLab才行!"
有18位网友表示赞同!
"感觉这个更新会对开源项目发展带来很大的帮助,提高开发效率也能加速创新!"
有17位网友表示赞同!
"希望未来版本还能增强通用目录的功能,支持更多类型的工具和平台!"
有19位网友表示赞同!
"GitLab越来越强大,这些新功能让我更期待接下来的发展了。"
有19位网友表示赞同!
"这个一键安装包真是太方便了,简直是开发者的福音!"
有8位网友表示赞同!
"部署流程变得更加简便直接,节省了很多时间和精力!"
有7位网友表示赞同!
"有了通用目录,我们可以更容易地共享和复用开发资源。"
有13位网友表示赞同!
"期待更多朋友能了解和使用GitLab这些强大的功能!"
有19位网友表示赞同!
"这次更新真是让开发流程更加高效便捷化!"
有13位网友表示赞同!
"终于不用再手动配置一遍遍CI/CD流程了,真是太开心了!"
有14位网友表示赞同!
"这款 GitLab 17.0真是什么都不缺,通用的目录、一键安装包,都太赞啦!"
有16位网友表示赞同!
"Ansible脚本的应用让我对GitLab未来的发展充满期待!"
有19位网友表示赞同!
"赶紧升级GitLab试试这个新功能吧!
有15位网友表示赞同!