In this article, we will see how to use Github Actions which is a continuous integration and continuous delivery tool with a Flutter Application.

• What Is Github Actions?
  • What is Continuous Integration (CI)?
  • What is Continuous Delivery (CD)?
• Explaining Workflow File
• Using Github Actions With Flutter

What Is Github Actions?

Github Actions is an automation software that helps in continuous integration and continuous delivery. It enables the developer to automate many different tasks like building, testing, analyzing and deploying.

What is Continuous Integration (CI)?

Continuous Integration is a practice in which developers commit their code daily to the repository. Every commit is then automatically built which will make it easier to detect different errors that may occur from the commits.

What is Continuous Delivery (CD)?

Continuous Delivery is when the software is automatically built, tested and ready for production. Therefore, continuous delivery helps in automating the release process, the only manual thing that has to be done is deciding when the release should occur.

There are also other CI/CD tools like Jenkins, CircleCI and TravisCI but in this tutorial we will focus on Github Actions.

Explaining Workflow File

To use Github Actions in your Github repository, then first you need to create the directory .github/workflows:

Now inside the workflows folder, you need to create yml files or workflows that will contain different jobs which will be triggered in response to a specific event (ex. after executing git push). For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
name: GitHub Actions Demo
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a $ event."
      - run: echo "🐧 This job is now running on a $ server hosted by GitHub!"
      - run: echo "🔎 The name of your branch is $ and your repository is $."
      - name: Check out repository code
        uses: actions/checkout@v2
      - run: echo "💡 The $ repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls $
      - run: echo "🍏 This job's status is $."

So the above is a basic workflow file, which we will explain it before showing an example with Flutter:

• name: This represents the name of this workflow file, that will be shown in the actions tab.

• on: This will contain the name of the event that will trigger this workflow, or it can contain a list of events, for example in the above file whenever we do a push this workflow file will be triggered.

• jobs: Each workflow run can contain one or more jobs. In the above example only one job is used.

• Explore-GitHub-Actions: This is the job Id.

• runs-on: Each job needs to run on a virtual machine (also called runners), in the above case we used ubuntu-latest, but you can also use windows-latest or macos-11.

• steps: Each job will contain multiple tasks called steps. A step can either be an action or a shell command.

• run: This will run the command provided to it, for example in the above file we use echo "🎉 The job was automatically triggered by a $ event that will print the above statement to the log.

• name: The name here is optional, but it can be used to identify the command or action in the log.

• uses: Selects an action to run as part of a step in your job, for example in the above file we used actions/checkout@v2. This action will check-out our repository so our workflow file can access it. Actions are basically commands combined together. You can find different actions here.

Using Github Actions With Flutter

Assuming you have a Flutter application and you want to automate the building, analyzing, and testing phase. Then you can create the following workflow file under .github/workflows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# This is a basic workflow to help you get started with Actions
name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [master]
    paths-ignore:
      - '**/README.md'
  pull_request:
    branches: [master]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

  # A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    name: flutter build
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    env:
      JAVA_VERSION: "11.0"
      FLUTTER_VERSION: "2.5.3"
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: $
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: $
      - run: flutter pub get
      - run: flutter analyze
      - run: flutter test

The above workflow will get triggered on every git push or pull request excluding changes on the README.md file. The workflow_dispatch will allow you to manually run this workflow on the Github UI. The job which has an id called build will run on the virtual machine ubuntu-latest and has a name called flutter build (name is optional).

Then we use the checkout action, that will check-out our repository so our workflow file can access it. Then we use the flutter action, which will set up a flutter environment to use in this action. So because we used this flutter action, we can run different flutter commands, like flutter pub get to get the packages, flutter analyze to check for lint issues and flutter test to run our tests.

Also to use the flutter action, you need to download the requested java version by using the actions/setup-java. The @v1 is the version of this action that is being used. Therefore now whenever you do a push this file will get triggered, you can check the logs under the Action tab of the repository, for example:

So here we get an error on the flutter analyze command, which we can then fix and execute git push again which will trigger this workflow file.

You can also create a different workflow file for deploying or releasing, for example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# This is a basic workflow to help you get started with Actions
name: Releases

# Controls when the workflow will run
on: 
  push:
  # Triggers the workflow on push or pull request events but only for the tagged
    tags:
    - '*'
  
  # A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  releases:
    name: release apk
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    env:
      JAVA_VERSION: "11.0"
      FLUTTER_VERSION: "2.0.0"
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v1
        with:
          java-version: $
      - uses: subosito/flutter-action@v1
        with:
          flutter-version: $
      - run: flutter pub get
      - run: flutter analyze
      - run: flutter test
      - run: flutter build apk --release
      - uses: ncipollo/release-action@v2
        with:
         artifacts: "build/app/outputs/flutter-apk/*.apk"
         token: $

The above workflow will trigger whenever we create a tag (Tags are used to label and mark a specific commit in the history, for example a version release) and push it to the remote repository. So here we also use the same flutter-action as the previous workflow file, but we also use the release-action and provide it the path toward the generated apk. The release-action will add the apk under the release tab in Github.

I hope you enjoyed reading this github action/flutter tutorial, please feel free to leave any comments or feedback on this post!