Continuous Integration (CI) and Continuous Delivery (CD) are crucial for maintaining high-quality mobile applications. GitHub Actions offers a seamless, flexible way to automate your Flutter app’s build, test, and deployment pipelines directly from GitHub.
In this guide, we’ll explore GitHub Actions’ fundamentals and walk through creating a CI/CD pipeline for a Flutter project, complete with a real-world example to help you get started quickly.
Why Use GitHub Actions?
- Native Integration: No need for external CI services; workflows run in the same ecosystem as your code.
- Free Usage for Public Repos: Generous free minutes for public repositories and an easy pay-as-you-go model for private repos.
- Extensibility: Thousands of community actions available on the GitHub Marketplace.
- Matrix Builds: Test across multiple OS versions or Flutter channels in parallel.
- Secrets Management: Securely store API keys, credentials, and certificates.
Key Concepts
1 .Workflow
A workflow is an automated procedure defined in a YAML file under the .github/workflows/ directory. It triggers on specific events (push, pull_request, schedule).
2. Job
A job is a set of steps that execute on the same runner. Jobs run in parallel by default.
3 .Step
A step is an individual task within a job. Steps can run commands or use actions.
4.Runner
A runner is a server that executes jobs. GitHub provides hosted runners (ubuntu-latest, macos-latest, windows-latest), or you can host your own.
-Setting Up Your Flutter Project
Ensure your Flutter project follows standard structure:
my_flutter_app/
├── .github/
│ └── workflows/
├── android/
├── ios/
├── lib/
├── test/
├── pubspec.yaml
└── README.md
Creating Your First Workflow
1-Directory Structure
In your project root, create the workflow directory:
mkdir -p .github/workflows
2-Basic Workflow YAML
Create .github/workflows/flutter-ci.yml:
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
steps:
- uses: actions/checkout@v3
- name: Set up Flutter
uses: subosito/flutter-action@v2
with:
flutter-version: 'stable'
- run: flutter pub get
- run: flutter analyze
- run: flutter test --coverage
you can absolutely add Windows support in your GitHub Actions workflow by using a matrix strategy that includes different operating systems such as ubuntu-latest, windows-latest, and macos-latest. This way, your Flutter project can be built and tested on multiple platforms, including Windows.
Workflow Breakdown
1. Checkout Code
- uses: actions/checkout@v3
Checks out your repository code so subsequent steps can access it.
2. Set Up Flutter
- name: Set up Flutter
uses: subosito/flutter-action@v2
with:
flutter-version: 'stable'
Installs the specified Flutter SDK and adds it to PATH.
3. Install Dependencies
- run: flutter pub get
Downloads Dart and Flutter packages defined in pubspec.yaml.
4. Run Code Linting
- run: flutter analyze
Checks for potential code issues.
5. Execute Tests
- run: flutter test --coverage
Runs unit and widget tests, generating a coverage report.
6. Build APK and IPA (Optional)
- name: Build APK
run: flutter build apk --release
- name: Build IPA
if: runner.os == 'macOS'
run: flutter build ipa --export-options-plist=ios/ExportOptions.plist
Produces the release binaries for Android and iOS.
Real-World Example
Below is a complete, real-world Flutter CI workflow with caching and code coverage upload:
name: Flutter CI/CD
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
analyze_and_test:
runs-on: ubuntu-latest
strategy:
matrix:
flutter-version: [ 'stable', 'beta' ]
steps:
- uses: actions/checkout@v3
- name: Cache Pub Packages
uses: actions/cache@v3
with:
path: ~/.pub-cache
key: ${{ runner.os }}-pub-${{ hashFiles('**/pubspec.yaml') }}
- name: Set up Flutter
uses: subosito/flutter-action@v2
with:
flutter-version: ${{ matrix.flutter-version }}
- run: flutter pub get
- run: flutter analyze
- name: Run Tests
run: flutter test --coverage
- name: Upload Coverage to Codecov
uses: codecov/codecov-action@v3
with:
files: coverage/lcov.info
token: ${{ secrets.CODECOV_TOKEN }}
build_release:
runs-on: ubuntu-latest
needs: analyze_and_test
steps:
- uses: actions/checkout@v3
- name: Set up Flutter
uses: subosito/flutter-action@v2
with:
flutter-version: 'stable'
- run: flutter pub get
- name: Build APK
run: flutter build apk --release
- name: Archive Release
uses: actions/upload-artifact@v3
with:
name: app-release-apk
path: build/app/outputs/flutter-apk/app-release.apk
Explanation:
-
Multi-version Testing: Runs tests on both
stableandbetachannels. -
Caching: Speeds up package installs using
actions/cache. - Artifact Upload: Persists build outputs for distribution.
- Coverage Reporting: Integrates with Codecov for test coverage visualization.
Optimizations and Best Practices
-
Use Caching: Speed up dependencies install with
actions/cache. - Matrix Builds: Test across Flutter channels and OS versions.
- Fail Fast: Separate linting and tests into early jobs to catch errors quickly.
- Secrets Management: Use GitHub Secrets for API tokens, keystore passwords, and code signing certificates.
- Self-hosted Runners: For custom build environments or faster hardware.
- Notifications: Integrate with Slack, Teams, or email for workflow status.
Conclusion
GitHub Actions offers a powerful, extensible platform for automating Flutter CI/CD. By following this step-by-step guide, you can set up robust pipelines that lint, test, build, and deploy your Flutter apps with ease. Start experimenting with matrix builds, caching strategies, and integrations to tailor your workflows to your team’s needs.
If you want us to talk about other alternatives to GitHub Actions, such as GitLab CI/CD , Local Fastlane , GitHub Actions Fastlane , Bitrise , or Codemagic, just leave a comment and let me know how many alternatives you’d like to explore!
references
https://docs.github.com/en/actions/about-github-actions/understanding-github-actions
Top comments (0)