# 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***](https://flutter.dev/docs/deployment/cd) section on the official Flutter Website.
[GitHub Actions](https://github.com/features/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](https://flutter.dev) app.
Sign up for GitHub Actions public beta, if you haven’t done so already - [here](https://github.com/features/actions).
### 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*](https://github.com/actions/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*](https://github.com/actions/setup-java)*.*
`lines 12–14`: Here we use the GitHub action [*flutter-action*](https://github.com/marketplace/actions/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*](https://github.com/marketplace/actions/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](https://github.com/settings/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 `/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 `/actions` and see the release files by going to `/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](https://github.com/nabilnalakath/flutter-githubaction)**.** If you face any issues please post them in the comments section**.**