In this tutorial, we are going to set up Continuous Integration (CI) for a Flutter project. CI is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests.
By the end of this tutorial, you will have a Flutter project with a CI pipeline that automatically builds and tests your application whenever you push changes to your repository.
Prerequisites:
- Basic knowledge of Flutter and Dart
- A Flutter project hosted on GitHub
- Familiarity with YAML files
We will be using GitHub Actions, a CI/CD system provided by GitHub. It uses a YAML file in your repository to define the actions that should be taken whenever certain events occur.
Create a new file in your repository at .github/workflows/ci.yaml
and open it in your text editor.
In the ci.yaml
file, define your workflow. Here's an example:
name: Flutter CI
on:
push:
branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
with:
java-version: '12.x'
- uses: subosito/flutter-action@v1
with:
flutter-version: '1.22.x'
- run: flutter pub get
- run: flutter test
- run: flutter build apk
This configuration will trigger the CI pipeline whenever you push to the master branch. It runs on the latest version of Ubuntu and executes the following steps:
flutter pub get
)flutter test
)flutter build apk
)Once you've saved your ci.yaml
file, add it to your repository and push your changes:
git add .github/workflows/ci.yaml
git commit -m "Setup CI"
git push
Let's add more actions to our workflow.
To avoid downloading dependencies every time the workflow runs, we can cache them:
# ... previous steps
- uses: actions/cache@v2
with:
path: "~/.pub-cache"
key: ${{ runner.os }}-pub-cache-${{ hashFiles('**/pubspec.lock') }}
restore-keys: |
${{ runner.os }}-pub-cache-
# ... next steps
This will cache the ~/.pub-cache
directory (where Flutter dependencies are stored) and use the hash of pubspec.lock
to know when the dependencies have changed.
You might want to keep the APK that was built. You can do this by uploading it as an artifact:
# ... previous steps
- uses: actions/upload-artifact@v2
with:
name: app
path: build/app/outputs/apk/release/app-release.apk
This will upload the APK built by flutter build apk
and make it available on the GitHub Actions page for the workflow run.
You've learned how to setup a CI pipeline for a Flutter project using GitHub Actions. This pipeline will automatically build and test your app whenever you push changes, catching bugs early.
Next, you could look into setting up Continuous Deployment, which is the next step in the CI/CD process. There are many services available for this, including GitHub Pages, Firebase, and others.
For additional resources, check the GitHub Actions documentation and the Flutter documentation.
Exercise 1: Setup a Flutter project locally and push it to a new GitHub repository. Then, setup a CI pipeline that runs tests whenever you push changes.
Exercise 2: Extend the CI pipeline from Exercise 1 by adding caching of dependencies.
Solution: The solutions for these exercises will be the same as the steps and examples provided above. The only difference is that the exact contents of the Flutter project will vary. The important part is that you have a pubspec.yaml
file and some Dart files to test.
Exercise 3: Extend the CI pipeline from Exercise 2 by building the APK and uploading it as an artifact.
Solution: The solution for this exercise will be the same as Example 2 above. The important part is that you add the actions/upload-artifact
action after the flutter build apk
command.