带有github动作的flutter项目的生命周期自动化

最新推荐文章于 2023-01-11 09:24:27 发布

weixin_26705651

最新推荐文章于 2023-01-11 09:24:27 发布

阅读量198

点赞数

文章标签： github python git java

原文链接：https://medium.com/better-programming/lifecycle-automation-of-a-flutter-project-with-github-actions-e26b8f106467

版权

In this article, I’m going to show you how I use GitHub Actions to automate the building and distribution of a Flutter app.

在本文中，我将向您展示如何使用GitHub Actions自动构建和分发Flutter应用。

First of all, I want to explain what GitHub Actions is. It’s basically a CI/CD tool from GitHub. It allows us to easily build, test, and deploy our code in GitHub. Our workflow utilizes reusable units called actions, which are developed by GitHub itself or a third party to perform one specific task in a workflow. So our workflow consists of a set of these actions.

首先，我想解释一下GitHub Actions是什么。它基本上是GitHub上的CI / CD工具。它使我们能够轻松地在GitHub中构建，测试和部署我们的代码。我们的工作流利用了可重复使用的单元，称为动作，由GitHub本身或第三方开发，以在工作流中执行一项特定任务。因此，我们的工作流程由一系列这些操作组成。

Let’s jump into what we need to do to automate the lifecycle of our Flutter project. GitHub Actions requires a YAML file to specify everything related to a workflow. So first, we create a xxx.yml file in the .github/workflows directory under our project. Here, xxx can be anything we want.

让我们跳入我们需要做的自动化Flutter项目生命周期的工作。 GitHub Actions需要一个YAML文件来指定与工作流程相关的所有内容。因此，首先，我们在项目下的.github/workflows目录中创建一个xxx.yml文件。在这里， xxx可以是我们想要的任何东西。

The first thing we’ll specify in this file is the name of our workflow:

我们将在此文件中指定的第一件事是工作流的名称：

name: app workflow

Afterward, we need to specify in which cases this workflow should be triggered. It can be done as follows:

之后，我们需要指定在什么情况下应触发此工作流程。可以按照以下步骤完成：

on:
  push:
    branches:- develop
      - masterpull_request:
    branches:- develop

In this example, we want our workflow to be triggered when there’s a code push made to the develop or master branch and also when a pull request is made to the develop branch.

在此示例中，我们希望在对develop或master分支进行代码推送时以及在对develop分支做出拉取请求时触发工作流。

Now it’s time to define our job. A job basically specifies a list of action steps and where these actions run. A workflow might contain multiple jobs, but for our simple case, we only have one job:

现在是时候定义我们的工作了。作业基本上指定了一系列操作步骤以及这些操作的运行位置。一个工作流程可能包含多个作业，但是对于我们的简单情况，我们只有一个作业：

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest    steps:...

For our job called build_and_deploy, we first specify on which machine this job should run. Here we use a Ubuntu machine with the latest stable version.

对于名为build_and_deploy的作业，我们首先指定该作业应在哪台计算机上运行。在这里，我们使用具有最新稳定版本的Ubuntu计算机。

Let’s now list the actions required for a complete CI/CD flow under the steps of our job. First, we need to prepare the environment on the device:

现在，让我们列出工作steps中完整CI / CD流程所需的操作。首先，我们需要在设备上准备环境：

steps:
  - uses: actions/checkout@v2- uses: actions/setup-java@v1with:
      java-version: 1.8  - name: Install NDKrun: echo "y" | sudo /usr/local/lib/android/sdk/tools/bin/sdkmanager --install "ndk;20.0.5594570" --sdk_root=${ANDROID_SDK_ROOT}  - name: Set up Flutter environment    uses: subosito/flutter-action@v1.3.2with:
      channel: stable  ...

I want to go step by step here:

我想在这里逐步进行：

Check out our repository, and make it ready to use in the machine by upcoming actions.
签出我们的存储库，并通过即将进行的操作使其可以在计算机中使用。
Set up the Java environment with Java version 8.
使用Java版本8设置Java环境。
As I’ve encountered errors related to the required Android NDK version not being found, I’ve added the step called “Install NDK,” which installs the required version specified in the error logs. You might not need this step at all. So try it yourself, and if that’s the case, you can simply remove it.
当我遇到与找不到所需的Android NDK版本相关的错误时，我添加了名为“安装NDK”的步骤，该步骤将安装错误日志中指定的所需版本。您可能根本不需要此步骤。因此，您可以自己尝试一下，如果是这种情况，只需将其删除即可。
Set up the Flutter environment with the latest stable version. This step uses an action developed by a third party. Read more here for details.
使用最新的稳定版本设置Flutter环境。此步骤使用第三方开发的操作。在此处了解更多信息。

If we recheck the initial steps given above, we set name only for some of them. If a step/action isn’t clear enough for us, we can provide a name to clearly explain what the purpose of that step is.

如果我们重新检查上面给出的初始步骤，则仅为其中一些设置name 。如果某个步骤/动作对我们来说还不够清楚，我们可以提供一个名称来清楚地说明该步骤的目的。

The environment setup is now completed. With step 4, we have the flutter tool installed on our device. Now, we can build the APK using Flutter commands:

现在，环境设置已完成。通过第4步，我们在设备上安装了flutter工具。现在，我们可以使用Flutter命令构建APK：

  - run: flutter pub get - run: flutter test  - run: flutter build apk --release --build-number=${GITHUB_RUN_NUMBER}  env:   KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }} STORE_PASSWORD: ${{ secrets.STORE_PASSWORD }}
  ...

Here, we first install the package dependencies. Then, we run the tests (if any). And finally, we build a release APK with build number set to GITHBU_RUN_NUMBER, which is an environment variable provided by GitHub. GitHub defines it as: “A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow’s first run, and increments with each new run. This number does not change if you re-run the workflow run.”

在这里，我们首先安装软件包依赖项。然后，我们运行测试(如果有)。最后，我们构建了一个发行版APK，其内部版本号设置为GITHBU_RUN_NUMBER ，这是GitHub提供的环境变量。 GitHub将其定义为：“存储库中特定工作流程的每次运行的唯一编号。对于工作流程的第一次运行，此数字从1开始，并在每次新运行时递增。如果您重新运行工作流程，此数字不会更改。”

Moreover, we need to provide two more environment variables, KEY_PASSWORD and STORE_PASSWORD, to be used while signing the APK. To be more specific, they’re used in theapp/build.gradle file on the Android side as follows:

此外，我们还需要提供两个环境变量KEY_PASSWORD和STORE_PASSWORD ，以便在对APK进行签名时使用。更具体地说，它们在Android端的app/build.gradle文件中使用，如下所示：

...signingConfigs {release {storeFile file("../keystore.jks")storePassword = "$System.env.STORE_PASSWORD"keyAlias = "myapp"keyPassword = "$System.env.KEY_PASSWORD"
  }
}buildTypes {release {signingConfig signingConfigs.release
    }
}...

Both of these variables should be added as secrets under our GitHub repository’s “Settings/Secrets” page. These secrets (environment variables) are automatically passed to our workflow while running.

这两个变量都应作为秘密添加到我们的GitHub存储库的“设置/秘密”页面下。这些秘密(环境变量)在运行时会自动传递给我们的工作流程。

After these steps, we should have a release APK ready to be deployed with the following file path: build/app/outputs/apk/release/app-release.apk. We’ll deploy this file to Firebase, and using its App Distribution service, we’ll distribute it to our testers. To do this, we have one last step remaining:

完成这些步骤之后，我们应该已经准备好使用以下文件路径来部署发布APK： build/app/outputs/apk/release/app-release.apk 。我们将此文件部署到Firebase，并使用其应用程序分发服务将其分发给测试人员。为此，我们还有最后一步：

  - name: Upload artifact to Firebase App Distribution    uses: wzieba/Firebase-Distribution-Github-Action@v1.2.2    with:  appId: ${{ secrets.FIREBASE_APP_ID }}      token: ${{ secrets.FIREBASE_TOKEN }}    groups: testers    file: build/app/outputs/apk/release/app-release.apk

Here, we again use a third-party action, this time for Firebase App Distribution. Action details can be found here. Basically, to make this action run successfully, we need to provide a couple of inputs:

在这里，我们再次使用第三方操作，这是Firebase App Distribution。动作细节可以在这里找到。基本上，要使此操作成功运行，我们需要提供一些输入：

appId can be found under the “Your apps” section on the project settings page of the Firebase dashboard.
appId 可以在Firebase仪表板的项目设置页面的“您的应用程序”部分下找到。
token can be generated on the local machine by using the following command: firebase login:ci. However, first we need to install the Firebase CLI on our machine. See here.
token 可以使用以下命令在本地计算机上生成： firebase login:ci 。但是，首先，我们需要在计算机上安装Firebase CLI。看这里。
groups is the name(s) of the tester group(s) we created on Firebase App Distribution and want to distribute our app to.
groups是我们在Firebase App Distribution上创建并想要将我们的应用分发到的测试者组的名称。
file is the path for our APK to be distributed.
file是我们APK分发的路径。

Similar to what we saw above while building the app, FIREBASE_APP_ID and FIREBASE_TOKEN also need to be set as repository secrets, as they’re used by this action. So our Secrets page looks like this at the end:

与上面在构建应用程序时看到的类似， FIREBASE_APP_ID和FIREBASE_TOKEN也需要设置为存储库机密，因为此操作使用了它们。因此，我们的“秘密”页面最后看起来像这样：

Image for post — Secrets page of our repository on GitHub

To keep the article short, I didn’t go into the details of Firebase App Distribution, but it’s basically another service of Firebase that allows us to distribute prerelease versions of our app easily to tester groups, notifying them via email. If you want to know more about it, read more here.

为了使本文简短，我没有详细介绍Firebase App Distribution，但它基本上是Firebase的另一项服务，它使我们能够轻松地将应用程序的预发行版本分发给测试人员组，并通过电子邮件通知它们。如果您想了解更多信息，请在此处阅读更多内容。

完整的YAML (Complete YAML)

Finally, I want to provide the complete YAML file just to see all bits together:

最后，我想提供完整的YAML文件，以便一起查看所有位：

name: app workflowon:
  push:
    branches:- develop
      - masterpull_request:
    branches:- developjobs:
  build_and_deploy:
    runs-on: ubuntu-latest  steps:
    - uses: actions/checkout@v2- uses: actions/setup-java@v1with:
        java-version: 1.8    - name: Install NDKrun: echo "y" | sudo /usr/local/lib/android/sdk/tools/bin/sdkmanager --install "ndk;20.0.5594570" --sdk_root=${ANDROID_SDK_ROOT}    - name: Set up Flutter environment      uses: subosito/flutter-action@v1.3.2with:
        channel: stable    - run: flutter pub get - run: flutter test    - run: flutter build apk --release --build-number=${GITHUB_RUN_NUMBER}    env:     KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}STORE_PASSWORD: ${{ secrets.STORE_PASSWORD }}    - name: Upload artifact to Firebase App Distribution      uses: wzieba/Firebase-Distribution-Github-Action@v1.2.2      with:    appId: ${{ secrets.FIREBASE_APP_ID }}        token: ${{ secrets.FIREBASE_TOKEN }}      groups: testers      file: build/app/outputs/apk/release/app-release.apk

This particular example was just for building and distributing an APK. By changing a couple of parts, we can easily create a workflow for iOS releases as well.

这个特定示例仅用于构建和分发APK。通过更改几个部分，我们也可以轻松地为iOS版本创建工作流程。

If you’re using GitHub as a code repository, I strongly recommend you give GitHub Actions a try as your CI/CD tool. It has a growing marketplace for actions, many of which are developed by the community.

如果您将GitHub用作代码存储库，则强烈建议您尝试使用GitHub Actions作为CI / CD工具。它具有不断增长的行动市场，其中许多是由社区开发的。

Take care until next time!

注意直到下次！

翻译自: https://medium.com/better-programming/lifecycle-automation-of-a-flutter-project-with-github-actions-e26b8f106467

weixin_26705651

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
带有github动作的flutter项目的生命周期自动化

In this article, I’m going to show you how I use GitHub Actions to automate the building and distribution of a Flutter app. 在本文中，我将向您展示如何使用GitHub Actions自动构建和分发Flutter应用。 First of all, I want to expl...
复制链接

扫一扫