Hello Human!

您好人类！

This tutorial is for you if

本教程适合您

• ✅ you have an Android or Kotlin or Java project built with Gradle

  ✅您有使用Gradle构建的Android或Kotlin或Java项目

• ✅ you write unit tests
  ✅您编写单元测试
• ❌ you have no Continuous Integration system setup to run your tests on the server
  ❌您没有持续集成系统设置程序可以在服务器上运行测试

Having the guarantee that your unit tests run on the build server is a keystone to establish a culture of testing withing your team — either at work or in an open-source project.

保证单元测试在构建服务器上运行是在团队中或在开源项目中与团队建立测试文化的基石。

Perhaps you know that already, and have been told that you could setup Jenkins or Travis or CircleCi. But you don’t even know which one to choose, let alone how to configure them.

也许您已经知道了，并被告知可以设置Jenkins或Travis或CircleCi 。 但是您甚至都不知道要选择哪个，更不用说如何配置它们了。

My goal is to convince you that you can start today setting up a pipeline with GitHub Actions and Gradle.

我的目标是说服您，您今天就可以开始使用GitHub Actions和Gradle建立管道。

我的工作流程 (My Workflow)

• Open your Android or Gradle project
  打开您的Android或Gradle项目

• Create a file called exactly .github/workflows/runOnGitHub.yml with this content

  使用此内容创建一个名为.github/workflows/runOnGitHub.yml的文件

# .github/workflows/runOnGitHub.yml
# GitHub Actions documentation
# => https://docs.github.com/en/actions
name: runOnGitHub


# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [ master, main ]
  pull_request:
    branches: [ master, main ]
jobs:
  gradle:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-java@v1
        with:
          java-version: 8


      # Execute Gradle commands in GitHub Actions workflows
      # => https://github.com/marketplace/actions/gradle-command
      - uses: eskatos/gradle-command-action@v1
        with:
          arguments: runOnGitHub
          wrapper-cache-enabled: true
          dependencies-cache-enabled: true
          configuration-cache-enabled: true

• Commit and push
  提交并推送
• Create a pull request
  创建请求请求

After a short while, you should see this:

片刻之后，您应该会看到：

The GitHub Action is failing.

GitHub操作失败。

That’s progress: before it was not even running!

那是进步：它甚至没有运行之前！

The next step is to follow the link “Details” to see what is going on.

下一步是单击“详细信息”链接以查看发生了什么。

定义任务./gradlew runOnGitHub (Define the task ./gradlew runOnGitHub)

Here is the error you will found in Details

这是您将在“详细信息”中发现的错误

Welcome to Gradle 6.6.1!FAILURE: Build failed with an exception.* What went wrong:
Task 'runOnGitHub' not found in root project '$YOUR_PROJECT'.BUILD FAILED in 1m 31s

That makes a ton of sense, we didn’t define the Gradle task runOnGitHub yet.

这很有意义，我们还没有定义Gradle任务runOnGitHub 。

Next:

下一个：

• Open the root build.gradle.kts or build.gradle file

  打开根build.gradle.kts或build.gradle文件

• Register a Gradle task called runOnGitHub like this:

  注册一个名为runOnGitHub的Gradle任务，如下所示：

tasks.register("runOnGitHub") { // 1
    dependsOn(":app:lint", ":app:testDebugUnitTest")  // 2 ==> CUSTOMIZE THIS LINE
    group = "custom"      // 3
    description = "$ ./gradlew runOnGitHub # runs on GitHub Action" //3
}

There are three steps

三个步骤

1. you register a new task called runOnGitHub
   您注册了一个名为runOnGitHub的新任务

2. you define via dependsOn() which tasks should be executed before runOnGitHub. In this example we run the linter and the unit tests in the app module. This is the crucial step that will depend from project to project. So be sure to customize it for your needs.

   您可以通过dependsOn()定义在runOnGitHub之前应执行哪些任务。 在此示例中，我们在app模块中运行了linter和单元测试。 这是至关重要的步骤，取决于每个项目。 因此，请务必根据您的需求对其进行自定义。

3. you document what will appear when you run ./gradlew tasks

   您记录运行./gradlew tasks时将显示的./gradlew tasks

推送到GitHub并通过Action (Push to GitHub and make the Action pass)

Once you have defined the task:

定义任务后：

• Run locally the task ./gradlew runOnGitHub and check it does what you want.

  在本地运行./gradlew runOnGitHub任务，并检查它是否满足您的要求。

• Tip: Save time by running ./gradlew --dry-run runOnGitHub to see quickly what tasks would be executed without actually running them.

  提示：通过运行./gradlew --dry-run runOnGitHub可以节省时间，以快速查看要执行哪些任务而不实际运行它们。

• Push to GitHub

  推送到GitHub

• Open the Actions tab on GitHub and if you are lucky you will see this after a while:

  在GitHub上打开“操作”标签，如果幸运的话，过一会儿您会看到以下信息：

• Celebrate

  庆祝

其他资源/信息(Additional Resources / Info)

To know more about creating your own Gradle tasks, follow the gentle tutorial at https://guides.gradle.org/writing-gradle-tasks/

要了解有关创建自己的Gradle任务的更多信息，请访问https://guides.gradle.org/writing-gradle-tasks/上的入门教程。

Read the docs about GitHub Actions

阅读有关GitHub Actions的文档

GitHub Actions Documentation

GitHub动作文档

Read the docs about the Gradle Command Action

阅读有关Gradle Command Action的文档

个人故事(Personal Story)

Some words on my personal experience with GitHub Actions, a word on unit tests vs android instrumentation tests, and a critic of GitHub YAML files.

关于我在GitHub Actions上的个人经历的一些词汇，关于单元测试与android工具测试的词汇，以及对GitHub YAML文件的批评。

使用GitHub Action发布库 (Using GitHub Action to publish libraries)

I have used GitHub Actions in the past for more complex workflows to publish libraries.

过去，我曾将GitHub Actions用于更复杂的工作流来发布库。

If you are interested, have a look here:

如果您有兴趣，请在这里看看：

https://github.com/jmfayard/refreshVersions/tree/master/.github/workflows

https://github.com/jmfayard/refreshVersions/tree/master/.github/workflows

https://github.com/LouisCAD/Splitties/tree/main/.github/workflows

https://github.com/LouisCAD/Splitties/tree/main/.github/workflows

But instead of talking about those complex ad hoc workflows, I thought it would be more interesting to help all Gradle and Android projects to make the first step to have continuous integration with GitHub Action and Gradle.

但是，我不想谈论那些复杂的临时工作流程，而是帮助所有Gradle和Android项目迈出第一步，使其与GitHub Action和Gradle进行持续集成会更加有趣。

I submitted two pull-requests, one to the Android app of DEV.to, the other to a friend’s project.

我提交了两个请求，一个请求到DEV.to的Android应用程序，另一个请求给一个朋友的项目。

If you look at the pull-request, one thing I have done is to setup the Gradle build-scan for better reporting when tests are failing. I wrote abouit here already:

如果您查看请求请求，那么我要做的一件事就是设置Gradle构建扫描，以在测试失败时更好地报告。 我已经在这里写过关于：

您的测试金字塔是否反转？ (Is your Testing Pyramid Inverted?)

A problem I encountered in the DEV-Android app is that it had very few unit tests

我在DEV-Android应用程序中遇到的一个问题是它的单元测试很少

Something to keep in mind if you have an Android project is that my workflow allows you to run the unit tests on GitHub, but not the integration tests / automated GUI tests also called Android instrumentation tests.

如果您有一个Android项目，要记住的一点是，我的工作流程允许您在GitHub上运行单元测试，但不能进行集成测试/自动GUI测试(也称为Android工具测试)。

There are good reasons for that.

有充分的理由。

Unit tests are fast, easier to write and lead faster to the discovery and fix of the bug when they fail.

单元测试速度快，易于编写，并且在失败时可以更快地导致错误的发现和修复。

This is why the recommended strategy is to have a testing pyramid where the emphasis is put on writing a lot of fast simple unit tests:

这就是为什么推荐的策略是拥有一个测试金字塔的原因，该金字塔的重点是编写大量快速简单的单元测试：

Unfortunately there is a common anti-pattern in the Android world where not enough emphasis is put on the unit tests. The testing pyramid looks like this and won’t probably last as long as the ones in Egypt:

不幸的是，Android世界中存在一种常见的反模式，其中对单元测试的重视不够。 测试金字塔看起来像这样，持续时间可能不会像埃及的金字塔那样长久：

To understand why it’s an anti-pattern, read the Google Testing blog: Just Say No to More End-to-End Tests

要了解为什么它是反模式，请阅读Google测试博客：拒绝更多端到端测试

Now if you want to start putting more emphasis on writing more unit tests, having this infrastructure in place with GitHub Action is a nice first step.

现在，如果您要开始着重于编写更多的单元测试，那么在GitHub Action中使用此基础架构是不错的第一步。

YAML是一种可怕的编程语言 (YAML is a terrible programming language)

My biggest frustration by far was due to those YAML “configuration files”.

到目前为止，我最大的挫败是由于这些YAML“配置文件”。

I use quotes here because I think that “configuration file” here is a lie.

我在这里使用引号是因为我认为这里的“配置文件”是一个谎言。

Look, we want to make a computer do stuff that are not trivial.

看，我们想让计算机做一些不平凡的事情。

What we are doing is writing a programming script.

我们正在做的是编写编程脚本。

What happens here is that someone at GitHub just made up a terrible programming language disguised as YAML. There are hundred things that can go wrong, the IDE won’t help you a bit, and it’s a mmajor time waster.

这里发生的是，GitHub上有人伪装成YAML构成了一种可怕的编程语言。 有几百种可能出错的东西，IDE不会帮到您，这浪费了很多时间。

The better alternative is to use an actual programming language.

更好的选择是使用实际的编程语言。

Not Bash.

不重击。

Just imagine how simpler it would be if the IDE could help you exactly as well as it helps you when you write your code.

试想一下，如果IDE可以在编写代码时提供与您一样的帮助，那么它会多么简单。

Well you don’t have to imagine because configuration as code is a thing in alternatives to GitHub Action for example in TeamCity from JetBrains

好吧，您不必想象，因为代码配置是GitHub Action的替代品，例如在JetBrains的TeamCity中

I hope GitHub will provide us something like this.

我希望GitHub将为我们提供类似的信息。

反馈？ (Feedback?)

I hope you will try setting up your first CI with GitHub Action + Gradle.

我希望您会尝试使用GitHub Action + Gradle设置您的第一个CI。

• Copy the file .github/workflows/runOnGitHub.yml

  复制文件.github / workflows / runOnGitHub.yml

• Define your Gradle task runOnGitHub

  定义您的Gradle任务runOnGitHub

• Create your pull request.
  创建您的请求请求。

Please leave a comment if that works for you. I usually only hear from what went wrong :)

如果适合您，请发表评论。 我通常只听错了:)