Flutter – Building and Releasing APK using GitHub Actions

Github Actions is a Github tool that allows users to create CI/CD pipelines directly in a Github project instead of going to a third-party website. It assists us in developing, testing, and releasing our project very conveniently. In this article, we’re going to build a workflow for our flutter project. We’ll first build the project using the workflow and then release the APK under the artifacts section of Github Actions.

Prerequisites: Basic understanding of Github Actions and writing Workflows using Github Actions. 

So now, as we have the basic understanding of how to write a workflow, let’s first create a Github project in flutter and create a .yml file named flutter-workflow.yml in .github/workflows directory under the project’s root directory. Start writing the code in that file.

name: Flutter CI

on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-java@v1
        with:
          java-version: '12.x'
      - uses: subosito/flutter-action@v1
        with:
          channel: 'beta'
      - run: flutter pub get
      - run: flutter format --set-exit-if-changed .
      - run: flutter analyze .
      - run: flutter build apk
      - uses: actions/upload-artifact@v1
        with:
          name: release-apk
          path: build/app/outputs/apk/release/app-release.apk

First of all, we give a name to our workflow, here the name is Flutter CI. Every workflow should have an ‘on’ block which commands the workflow to get triggered as soon as the action defined in that block is reached. In our case, we have specified that wherever there will be a new push in the master branch, the workflow will get triggered. Jobs are the crucial part of a workflow, which will have details about the tasks that have to be done. Here we have specified only one job which is build.  Every build has to go through a setup of the virtual environment which is specified in the runs-on section. Here we are using Github-hosted ubuntu-latest. 

Now comes the steps section, in which we define the steps that will be executed when the workflow gets triggered. For building our code, we have to first checkout to our repository by writing actions/checkout@v1. 

The next step would involve the setting up of java by actions/setup-java@v1. As we setup the java, we have to setup flutter too in order to build our app. Hence we define subosito/flutter-action@v1. When we have set up java and flutter, we have to get the dependencies of flutter in order to build the project. So we define flutter pub get. Once we get the dependencies, we format our code, flutter format –set-exit-if-changed. flutter analyze . runs the static analysis of our code.

Now comes the main part to build the apk and upload the APK to the artifacts section. For that, we say flutter build apk and upload the APK using actions/upload-artifact@v1 from the directory build/app/outputs/apk/release/app-release.apk to the Artifacts section of our project. After writing the code commit it by giving a message and go to the Actions tab in order to see the workflow running.

After the build that is running gets completed, click again on the Actions tab and then click on the latest workflow that just completed running. Scroll to the bottom of the page and you’ll see an apk named release-apk in the artifacts section.

In this way, we created a workflow that will let you build the artifacts every time there is a new push in the main codebase i.e. master branch, and upload the newly build APK to the artifacts section of Github Actions.