一种更好的在 GitHub Actions 中使用 Gradle 的方式

Calendar - Gradle 构建系统
Daz DeBoer
通用

目录

在 GitHub Actions 上运行 Gradle 构建 #

GitHub Actions 为托管在 GitHub 上的项目提供了方便强大的 CI 平台。为了提升在 GitHub Actions 上构建 Gradle 项目的体验，Gradle 团队开发了 gradle-build-action。结合 Gradle Build Scans™，gradle-build-action 提供了 Gradle 和 GitHub Actions 之间的深度集成，从而在通过 GitHub Actions 构建和测试 Gradle 项目时提供更简单的设置和更好的体验。

gradle-build-action 是在 GitHub Actions 中运行 Gradle 构建的官方支持的方式，负责为您的 GitHub Actions 工作流准备和优化 Gradle。当应用于工作流时，所有后续的 Gradle 调用都将被优化，让您只需在常规工作流步骤中运行 ./gradlew build。

gradle-build-action 提供的主要功能是：

  • 下载并安装指定的 Gradle 版本（如果需要）
  • 在工作流运行之间保存和恢复 Gradle 用户主目录
  • 显示工作流中执行的任何 Gradle 构建的结果和 Gradle Build Scan

以下将详细介绍每个功能。

使用 Gradle Build Action #

通过将设置步骤添加到现有的 GitHub Actions 工作流，可以轻松利用 gradle-build-action，这类似于您使用 actions/setup-java action 为工作流配置 JVM 的方式。

gh-actions1

有关如何在工作流中使用 gradle-build-action 的详细信息，请参阅 Gradle Build Tool 文档或 README。

Gradle Build Action 的功能 #

在工作流运行之间保存和恢复 Gradle 用户主目录 #

Gradle 用户主目录会持久化许多有价值的状态，这些状态可以加快 Gradle 的后续调用速度。下载的依赖项、编译的构建脚本、本地构建缓存和生成的 API jar 都存储在 Gradle 用户主目录中。

每个 GitHub Actions 作业都在一个新的构建运行器上运行，这意味着它将从一个空的 Gradle 用户主目录开始。幸运的是，GitHub Actions 提供了一个缓存机制，允许在运行一个作业后保存 Gradle 用户主目录的状态，并在运行另一个作业之前恢复它。这可以大大缩短 Gradle 构建的运行时间，消除了重新下载依赖项、重新生成 Gradle API jar 等的需要。

然而，正确处理缓存并非易事。很容易保存过多的状态（快速填满 GitHub Actions 缓存），或者缓存键指定不充分（导致重要内容被省略）。

gradle-build-action 会为您处理这些细节，以作业特定的方式保存和恢复 Gradle 用户主目录中最重要的文件，同时提取通用文件并单独保存它们，以减少存储条目的冗余。大部分行为都是可配置和可调整的。有关 gradle-build-action 所采用的保存/恢复策略（以及相关的配置选项）的详细信息将在未来的帖子中介绍。

为每次构建显示结果和 Gradle Build Scan #

默认情况下，GitHub Actions 与 Gradle 的集成程度不如某些其他 CI 平台。它不提供构建结果的高级视图，也不提供对通过和失败的测试的良好渲染显示。相反，您需要检查日志以获取任何失败消息，并且测试报告需要保存为构建工件，可以下载这些工件来检查任何测试失败。

但是，通过使用 gradle-build-action 并配置每次 Gradle 调用以发布 Build Scans，您可以设置您的 GitHub Actions 工作流，以提供您期望的这些可用性功能。gradle-build-action 会检测所有 Gradle 构建调用，捕获诸如已执行的任务、构建结果以及任何生成的 Build Scan 的链接等详细信息。而链接的 Gradle Build Scan 提供了构建执行的完整视图，包括所有构建日志、完整的任务时间线、测试输出、已解析的依赖项以及您构建的性能特征。

gh-actions2

有关更多详细信息，请阅读 Google AndroidX 团队如何利用 gradle-build-action 和 Gradle Build Scans 来帮助他们在 GitHub Actions CI 环境中更快地解决构建和测试失败的问题。

使用指定的 Gradle 版本执行构建 #

我们建议大多数项目使用 Gradle Wrapper 来运行 Gradle，并且默认情况下 gradle-build-action 不会下载或安装 Gradle Distribution。但在某些情况下，您可能希望使用不同版本的 Gradle 来运行构建：例如，您想使用 Gradle release-candidate 来进行冒烟测试，或者您想使用一系列不同的 Gradle 版本来测试您的插件示例。

为此，gradle-build-action 能够下载和安装任何版本的 Gradle。如果向 action 提供了一个 'gradle-version' 参数，它将下载（并缓存）Gradle distribution zip，安装它，并将其添加到 PATH。像 'latest'、'release-candidate' 和 'nightly' 这样的别名也得到支持。然后，当您在后续工作流步骤中运行 gradle 时，将使用此安装的版本。

为什么要使用 gradle-build-action？ #

如果您熟悉 GitHub Actions，您可能想知道为什么要在工作流运行之间使用 gradle-build-action，而不是简单地配置 actions/cache 或 actions/setup-java 来保存和恢复 Gradle 依赖项。

我们相信 gradle-build-action 提供了显著的优势：请查看 action README 的这一部分。如果您仍有疑问，请随时在 https://github.com/gradle/gradle-build-action/issues 提问。

在 Gradle 和 GitHub Actions 之间获得更好的体验 #

gradle-build-action 提供了一种简单有效的方式在 GitHub Actions 上运行 Gradle 构建，最大限度地利用 GitHub Actions 缓存，并展示有关每次 Gradle 执行的重要信息。当与免费的 Gradle Build Scans（或自托管的 Gradle Enterprise Build Scans）结合使用时，在 GitHub Actions 上运行 Gradle 构建比以往任何时候都更好。

讨论

相关帖子