CI/CD for Flutter Apps Using GitHub Actions

The project featured on flutter.io to configure GitHub Actions for a Flutter project to test, build, and release an APK.

GitHub actions for Flutter.

This project is now featured in the Continuous Deployment section on the official Flutter Website.

GitHub Actions, the automation tool to add CI/CD workflow for projects on GitHub is currently available in beta. ( Update- Github Actions is now officially out of beta )

Even though the public release is still more than a month away on November 13, the GitHub marketplace has already seen a good number of Actions to help with CI/CD for almost all major platforms.

In this article, we will talk about the various steps to integrate the CI/CD workflow for a Flutter app.

1. Creating a GitHub Project

The first and obvious step is to create a GitHub project and connect your Flutter project with the repository.

If you have successfully completed the sign-up process for Actions beta, you should be able to see a new Actions tab for your project right next to pull requests.

Actions tab in the repository.

2. Adding Workflow file

GitHub provides many predefined workflows for the most popular platforms out there, and you can customize or create entirely new ones as well, in a visual editor.

But, in this project, we will be following the manual approach of creating a YAML file with the workflow commands.

In the root folder of your Flutter project, create a new folder .github and create a subfolder workflows. This is where our workflow YAML files will reside.

A project can have multiple workflow files like build, release, etc., but for the sake of simplicity, we will be using only one file for this project. Create one final file, named main.yml, in the workflow folder.

Creating GitHub folder and adding the workflow file

3. Writing Commands

The first thing that we define is the event on which we want our workflow to be triggered. This can be any GitHub event like push, pull_request, create, etc., based on your requirements.

In this project, we will be using the push event. We can also add a name to the workflow to identify it. Here’s the entire code for main.yml. For better understanding, we will go through each line and its use.

main.yml

line 1: We want to trigger our workflow when someone pushes the code to our repo.

lines 3–6: We are defining a job Build APK which runs on ubuntu-latest. Each job runs in a fresh instance of a virtual environment. A job can contain one or more steps.

line 8: This is the first step in our workflow. We will pull the source code from our repository and, for this, we will use a GitHub Action called checkout. This action checks out your repository to $GITHUB_WORKSPACE, so that your workflow can access the contents of your repository.

lines 9-11: In step two, we will set up a Java environment required for building an Android app using another GitHub Action, called setup-java.

lines 12–14: Here we use the GitHub action flutter-action which sets up a Flutter environment for use in actions.

line 15: Getting the dependencies for the Flutter project.

line 16: Run tests for Flutter.

line 16: Build debug APK of the app. —- split-per-abi is used to build multiple APKs and avoid building a fat APK that contains your code compiled for all the target ABIs

line 17: Pushing the APK to releases for the repository using a GitHub Action Create Release. Here, we specify the path where the APKs are stored after building and specifying *.apk to ensure that both the APKs are pushed to release.

The secrets.TOKEN is an API token that grants access to the repository. We will create one and add it to our project in the next step.

4. Adding a GitHub Token

Most of us would have created a GitHub token at some point for repository access and if you haven’t, the process very simple and straight forward.

Go to the personal access tokens section in your GitHub settings.
Generate a new token which has scope for repository access and copy its value.
Go to the repository settings for your project at <repo url>/settings/secrets. In the Secrets tab, add a new secret with the same token name from your workflow file (TOKEN in this project) and paste the token value.

Adding a new token in repository settings.

5. Pushing Code With Tags

Once we have created the workflow files and added tokens to our project, we can push the code to GitHub with release tags and trigger the workflow.

In your local project, commit all the files including the main.yml and add a new tag using the git tag command and push the code along with the tag.

Example:

git tag v1.0

git push origin v1.0

Seeing the Workflow and Release in GitHub

Once you have pushed the code you can see the workflow in action by going to <repo URL>/actions and see the release files by going to <repo URL>/releases.

History of workflows triggered

Workflow commands getting executed for a push event

APKs in the release section of the repository

That’s it. You can find the complete source code of the project on GitHub. If you face any issues please post them in the comments section.