Flutter CI/CD with GitHub Actions: Automate Testing and Builds

#flutter #githubactions #cicd #dart

Flutter CI/CD with GitHub Actions: Automate Testing and Builds

Manually running tests and building Flutter applications before every release is slow and error-prone.

With GitHub Actions, you can automate Flutter analysis, testing, artifact creation, and deployment workflows whenever code changes.

In this tutorial, we will create a basic CI pipeline that runs on every pull request and push.

The Workflow

Our pipeline will:

Check out the repository.
Install Flutter.
Fetch dependencies.
Run static analysis.
Run tests.
Build an Android artifact.

The same foundation can later be extended for app-store deployment.

Create the Workflow File

Create:

.github/
└── workflows/
    └── flutter.yml

Add the following:

name: Flutter CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable

      - name: Install dependencies
        run: flutter pub get

      - name: Analyze
        run: flutter analyze

      - name: Test
        run: flutter test

      - name: Build APK
        run: flutter build apk --release

Pin action versions appropriately for your organization's security and maintenance policy.

Run Tests Automatically

A pull request should fail when tests fail.

You can expand the test stage:

- name: Unit tests
  run: flutter test

- name: Widget tests
  run: flutter test test/widget_test.dart

For integration tests, use an emulator or a dedicated device-testing workflow.

Build Release Artifacts

After building the APK, upload it as a workflow artifact:

- name: Upload APK
  uses: actions/upload-artifact@v4
  with:
    name: flutter-apk
    path: build/app/outputs/flutter-apk/app-release.apk

This allows team members to download the generated build from the GitHub Actions run.

Environment Variables and Secrets

Never commit passwords, signing keys, API secrets, or service credentials.

Use GitHub repository or environment secrets:

env:
  API_URL: ${{ secrets.API_URL }}

For production signing, store sensitive signing material using an appropriate secret-management strategy.

Separate CI and CD

A useful production setup is:

Pull Request
     ↓
Analyze → Test
     ↓
Merge to main
     ↓
Build
     ↓
Release Approval
     ↓
Deploy

Separating validation from deployment reduces the risk of accidentally publishing an untested build.

Build Flavors

For larger applications, create environments such as:

development
staging
production

Each environment can have different API endpoints and configuration.

Your GitHub Actions workflow can select the appropriate Flutter flavor:

flutter build apk   --release   --flavor production

Improve Pipeline Speed

CI time can be reduced by:

Caching Flutter dependencies.
Running independent jobs in parallel.
Avoiding unnecessary builds.
Using targeted tests for fast pull-request feedback.

Production CI/CD Checklist

Before using the workflow for releases:

Protect the main branch.
Require successful checks before merging.
Store secrets in GitHub Secrets.
Use release approvals for production.
Keep action versions maintained.
Test release builds separately from debug builds.
Keep signing credentials outside source control.

Conclusion

GitHub Actions can turn Flutter development into a repeatable CI/CD process. Instead of manually checking every change, your repository can automatically analyze code, run tests, build release artifacts, and eventually deploy applications.

Start with a simple CI pipeline and gradually add signing, flavors, deployment, release approvals, and monitoring as your project becomes more mature.

Stay tuned for more DevOps and Flutter development tutorials!