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.
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.
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.
Sign up for GitHub Actions public beta, if you haven’t done so already - here.
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.
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.
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.
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
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.
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 (
TOKENin this project) and paste the token value.
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.
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
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.