如何自动更新项目依赖的版本? 开源项目 Renovate, 用Renovate自动更新项目依赖

enebgo

已于 2024-09-26 02:16:19 修改

阅读量1.5k

点赞数 14

分类专栏： DevOps # Git 文章标签：开源 python java git github ci/cd go

于 2024-09-26 02:13:00 首次发布

本文链接：https://blog.csdn.net/2402_87605821/article/details/142536387

版权

DevOps 同时被 2 个专栏收录

2 篇文章

订阅专栏

Git

2 篇文章

订阅专栏

用Renovate自动更新依赖

随着开发团队努力维护安全、高效和现代化的项目，管理依赖项的任务变得越来越重要。安全且最新的依赖项不仅可以防范漏洞，还可以提高整个系统的性能和可靠性。

在之前的文章中，我们探讨了约定式提交（conventional commits）的概念，强调约定式提交如何帮助标准化提交信息以提高项目的可管理性和促进自动化。

继续这一主题，今天我们将探讨一个自动化的依赖更新工具 —— Renovate，这是一个旨在简化依赖管理的自动化工具。Renovate自动化了更新过程，确保项目依赖被持续且可靠地管理，以维护项目的完整性和安全性。

ref
官方文档(似乎没中文): https://docs.renovatebot.com/
项目地址: https://github.com/renovatebot/renovate

文章主要介绍了Renovate工具的优势以及其如何帮助实现自动化依赖更新管理。如果你只希望初步了解该工具，可以选择不阅读详细的应用章节。虽然Renovate可以在本地及多种托管平台使用，但本文仅讨论其在GitHub上的应用。

什么是Renovate?

Renovate是一个开源工具，旨在自动保持项目依赖关系的更新。通过监控项目的依赖文件（如package.json、Pipfile或Gemfile），Renovate识别过时的依赖，并自动提交PR进行依赖的更新。

这种自动化不仅节省了开发人员的时间，而且确保项目包含其依赖项的最新安全补丁和功能。

Renovate的关键特性

自动化提交PR：自动为依赖更新提出PR，确保最小的手动干预。
可定制配置：提供广泛的可配置性，允许自定义更新的频率，将依赖分组进行同时更新，等等。
广泛的包管理器支持：支持跨编程语言的各种包管理器。
- NPM 用于JavaScript/Node.js
- pip 用于Python项目
- Maven 用于Java项目
- Gradle 用于Java和Android项目
- NuGet 用于.NET项目
- Composer 用于PHP项目
- Go Modules 用于Go项目
- RubyGems 用于Ruby项目
- CocoaPods 用于iOS项目
- Docker 用于管理Docker镜像
- Git Submodules 用于包含子模块的项目
- Terraform 用于基础设施即代码
私有和公共仓库支持：可用于私有和公共仓库。

为什么使用Renovate?

保持最新：自动保持依赖项更新至最新版本。
降低安全风险：通过更新可能具有安全补丁的依赖项来最小化漏洞。
节省时间：减少手动更新依赖项所需的时间。
提高兼容性：确保项目依赖项兼容更新，减少集成问题。
可定制和可扩展：自定义配置Renovate以最适合团队的工作流程，并在项目中进行扩展。

支持的平台

Renovate 与多种版本控制平台兼容，这些平台在不同的组织中广泛使用，确保了它能无缝集成到大多数开发工作流中。以下是Renovate支持的平台列表：

GitHub（.com和Enterprise Server）
GitLab（.com和CE/EE）
Bitbucket Cloud
Bitbucket Server
Azure DevOps
AWS CodeCommit
Gitea 和 Forgejo
Gerrit（实验性）

广泛的平台支持使不同的开发团队能够利用Renovate的自动依赖管理功能，无论他们现有的版本控制系统是什么，都能提高生产力并在各个平台上保持软件质量。

谁在使用Renovate?

Renovate在开发者社区中得到了广泛使用：
在这里插入图片描述

Renovate如何识别过时的依赖项？

Renovate通过检查仓库中的依赖文件来识别过时的依赖项。以下是Renovate执行的逐步解释：

扫描依赖文件：Renovate首先扫描仓库以寻找已识别的依赖文件。常见的例子包括JavaScript项目的package.json、Ruby的Gemfile、Python的Pipfile，以及其他根据使用的编程语言和包管理器而定的文件。
解析依赖详情：在检测到这些文件后，Renovate解析文件中提到的每个依赖的具体详情。这包括当前的版本号以及指定的需求或版本范围。
检查可用更新：接着，Renovate访问相应的包注册中心（如JavaScript的npm，Python的PyPI，Ruby的RubyGems等），以查找列出的依赖项的最新可用版本。
比较版本：拿到注册中心的最新版本后，Renovate将这些版本与项目依赖文件中当前指定的版本进行比较。它通过检查最新可用版本是否超出文件中指定的范围，或者是否有在相同主版本范围内的更新版本（取决于项目的配置设置），来识别哪些依赖项已过时。
解析依赖：对于具有深依赖树的语言（如JavaScript），Renovate还会解析依赖的依赖（传递依赖），以确保更新不会破坏项目。这一步骤至关重要，因为更新一个包可能需要或不兼容特定版本的其他包。
创建PR：对于每个过时的依赖项，Renovate会生成包含更新的包文件的PR。这些PR可以配置为包含详细的发布说明、兼容性评分，以及更改摘要，帮助开发者做出关于合并更新的决策。

这些步骤会以项目的Renovate配置中定义的频率重复进行，例如每日或每周一次，确保不间断地监控和更新依赖项，无需人工干预。Renovate的自动化过程极大地简化了维护最新依赖项的过程，从而增加了项目的安全性和稳定性。

Renovate将采用哪种类型的版本更新，哪种则不会？

Renovate可以根据项目需求配置处理不同类型的版本更新。以下是Renovate可以采用的类型及默认通常不会自动采用的类型的概览：

Renovate将采用的版本更新类型：

补丁更新：这些通常是在同一小版本内的错误修复。补丁更新（例如，从1.0.0到1.0.1）被认为是安全的，因为根据语义版本控制规则，它们不应引入重大变更。
小更新：这些更新（例如，从1.0到1.1）以向后兼容的方式添加功能。如果项目单元测试通过，且假设项目有良好的测试覆盖率，Renovate可以配置为自动合并这些更新。
大更新：尽管可能会引起问题，大更新（例如，从1.x到2.x）也可以由Renovate管理。它小心地处理这些更新，通常将它们放在单独的分支和PR 中，以便进行手动审查和测试，以确保兼容性。
依赖固定：对于某些项目，可能需要将依赖固定到特定版本，如果一个依赖被固定到特定版本，Renovate 则不会更新该依赖，并且除非Renovate配置中明确指示，否则不会自动将其更新到最新版本。

Renovate通常不会自动采用的版本更新类型：

预发布版本：除非明确配置，否则Renovate默认不会更新到预发布版本（alpha、beta、RC）。这是因为预发布版本通常稳定性较差，仅用于测试而非生产环境。
需要配置更改的更新：如果更新需要更改项目配置或代码更改（除版本号外），Renovate通常不会自动执行这些更新。这种情况通常需要手动干预以确保兼容性。
取消对某些功能的支持的更新：如果一个依赖的新版本取消对项目使用的语言、框架或工具的版本的支持，Renovate默认不会采用这些更新。这有助于避免破坏项目构建或功能。
关键依赖的大更新无兼容性评分：对于一些关键或复杂的依赖，大更新可能默认被忽略，直到通过Renovate提供的更新的兼容性评分或通过手动测试评估兼容性。

配置驱动选择

需要注意的是，Renovate 可高度自定义配置，可以通过项目中的renovate.json配置文件定制其行为。指定允许哪些类型的更新，是否应自动合并，以及是否包括预发布版本和大版本。这种灵活性使Renovate能够适应各种工作流程和项目需求，使其成为依赖管理的多功能工具。

Renovate 作为 DevOps 工具

Renovate 越来越被认为是 DevOps 实践中的一种有价值的工具，专注于简化和自动化依赖管理过程。随着团队致力于加快部署周期并提高系统可靠性，Renovate 提供了一种主动的解决方案，以保持所有项目依赖项的更新，这是维护软件健康和安全的重要方面。

如需了解更多有关各种用例的信息，并探索 Renovate 如何适应不同的 DevOps 策略，请参阅 Renovate Use Cases 上提供的全面文档。

在GitHub 项目中安装和引入 Renovate

在GitHub 项目中实施 Renovate 是一个简单的过程，以下是在 GitHub 上设置 Renovate 的方法：

第1步：仓库安装：在仓库中添加 Renovate

首先，在GitHub 仓库上安装 Renovate 应用。导航至 https://github.com/apps/renovate 并install：
在这里插入图片描述

你需要做的唯一选择是决定是在所有仓库上运行 Renovate 还是仅在选定的仓库上运行：
在这里插入图片描述
Renovate 将忽略任何没有已知包文件的仓库以及任何分支，因此在所有仓库上启用 Renovate 不会有任何问题。

选择完 Renovate 将要运行的仓库后，点击页面底部的绿色安装按钮，Renovate 将启用这些仓库并开始上线过程。

第2步：仓库上线和配置 Renovate

无风险的上线

Renovate 不会对仓库做任何更改或提出任何进一步的 Pull Request，直到合并。

你可以在 renovate/configure 分支 中编辑你的 Renovate 配置，Renovate 将继续更新 PR，因此你可以在满意结果之前继续调整配置。

检查警告: 如果有任何警告或错误，查看是否需要或希望进行任何更改。警告和错误应该在基础分支（例如 main）上修复，以便 Renovate 可以在下一个周期重新创建PR 。

配置 Renovate

“Configure Renovate” PR 将在根目录中包括一个 renovate.json 文件，其中提供了建议的默认设置。

你可以自定义此文件以指定 Renovate 应如何更新依赖项。这里有一个配置的基本示例：

{
  "extends": ["config:base"],
  "schedule": ["every weekend"],
  "assignees": ["your-github-username"],
  "labels": ["dependencies", "automerge"]
}

在 Renovate 配置中的 "extends": ["config:base"] 行意味着配置将继承 Renovate 提供的预定义基础设置中的设置。这个基础设置包括适用于大多数项目的推荐默认设置，可以帮助有效地自动化依赖更新。

此配置指示 Renovate 每个周末运行，自动 将 pull request分配给你，并 用 "dependencies" 和 "automerge" 标签标记这些 pull request。

自定义默认值

有时 Renovate 检测到需要对这些默认值进行覆盖，并将自动添加此覆盖，例如：

自动启用 Angular 风格的语义提交
根据检测到的项目类型（应用程序 vs 库）确定是否使用依赖范围固定依赖版本

常见自定义配置

这里是一些最常更改的自定义配置设置：

rangeStrategy：默认情况下（零配置）是 "replace"，但 "config:recommended" 预设将其覆盖为 "auto"。有些人可能更喜欢 "bump"。
labels：分配给 Pull Requests 的标签
assignees：分配给 Pull Requests 的 GitHub 用户

Renovate 将在发现更改时更新PR 描述。

有关详尽的配置参考：
https://docs.renovatebot.com/config-overview/
https://docs.renovatebot.com/mend-hosted/hosted-apps-config/

第3步：合并 Renovate 的初始 Pull Requests

一旦配置了 Renovate，它将开始创建 pull request 以更新每个过时的依赖项。最初，你可能会看到大量的PR ，因为 Renovate 会处理现有的依赖项，检查并合并这些 pull request。

第4步：监控和调整

在初始设置和更新之后，监控 Renovate 创建的 pull request并根据需要调整 renovate.json 配置。可能需要根据项目需求和团队的工作流程，微调更新计划、更新的依赖项选择或自动合并规则。

更改Renovate 配置

如果你需要修改你的的 Renovate 配置。有两种推荐的方法：

通过 PR 重新配置
删除配置并重新引导

通过 PR 重新配置

如果你想直接进行配置编辑，请按照以下步骤操作：

创建一个新的 Git 分支
全局安装或更新 renovate 包（使用 npm i -g renovate 或 yarn global add renovate），以获取 renovate-config-validator 程序
编辑你的 Renovate 配置文件
验证你的配置
如果改进的配置通过验证，将分支合并到你的主线分支中