Continuous Integration Pipeline
Relevant source files
The following files were used as context for generating this wiki page:
The BT Speaker project utilizes a Continuous Integration (CI) pipeline designed to manage its Flutter-embedded monorepo structure. The pipeline automates the validation of code across the pi_app, phone_app, and bt_speaker_core packages using a matrix-based approach in GitHub Actions. It ensures code quality through static analysis, consistent formatting, and automated testing with coverage reporting.
The core of the CI orchestration relies on Melos 7.x, which manages multi-package tasks such as dependency resolution, cross-package analysis, and conditional test execution. This setup allows the pipeline to efficiently validate changes while accounting for the specific requirements of each component, such as the pi_app's unique target for flutter-pi on ARMv7 hardware.
Sources: CLAUDE.md:1-24, README.md:46-52
Monorepo CI Orchestration
The pipeline is governed by Melos, which handles workspace-wide scripts. The configuration uses Melos 7.x workspace resolution to manage dependencies and execute tasks across the three primary packages.
Melos Scripts and Workflows
The CI pipeline executes specific scripts defined in the workspace configuration to validate code against the main branch.
The diagram shows the logical flow of the CI pipeline from trigger to final status.
Sources: melos.yaml:3-28, pubspec.yaml:16-43, CLAUDE.md:16-18
CI Command Summary
| Script Name | Command | Purpose | Target |
|---|---|---|---|
analyze | melos exec -- flutter analyze --fatal-infos | Static code analysis | Changed packages vs origin/main |
format | melos exec -- dart format --set-exit-if-changed . | Code style validation | Changed packages vs origin/main |
test | melos exec -- flutter test --coverage | Unit and integration testing | Packages with test/ directory |
lint | melos run analyze && melos run format | Combined quality check | Changed packages |
Sources: melos.yaml:3-23, pubspec.yaml:18-36
Testing and Coverage
The CI pipeline includes a robust testing phase that utilizes flutter_test, bloc_test, and mocktail. Tests are executed with a randomized ordering seed to ensure stability.
Test Execution Logic
A critical safeguard in the CI pipeline is the check for the existence of a test directory. This prevents build failures in packages that do not yet have a test suite, such as phone_app in its current state.
This diagram illustrates the conditional logic used by Melos to filter packages during the test phase.
Sources: melos.yaml:16-23, CLAUDE.md:80-83, README.md:52
Dependency Management
Each package maintains its own pubspec.yaml but is resolved through the root workspace.
- pi_app: Depends on
bt_speaker_core,flutter_bloc, andequatable. Usesbloc_testandvery_good_analysisfor CI quality. - phone_app: Includes additional dependencies like
app_links,crypto, andhttp. Usesmocktailfor testing. - bt_speaker_core: Shared library providing models for the entire system.
Sources: apps/pi_app/pubspec.yaml:34-45, apps/phone_app/pubspec.yaml:35-51, packages/bt_speaker_core/pubspec.yaml:13-20
Target Platform Considerations
While the CI pipeline runs on standard runners, it must respect the target hardware constraints of the project, specifically for the pi_app.
Hardware Architecture Guardrails
The pi_app is built specifically for Raspberry Pi Zero 2 W. The CI must ensure that builds do not assume aarch64 as the target is strictly armv7 (32-bit).
| Component | Specification |
|---|---|
| Architecture | armv7 (never aarch64) |
| CPU | generic (ARM Cortex-A53) |
| Flutter Version | 3.41.9 stable |
| Build Tool | flutterpi_tool |
Sources: CLAUDE.md:27-31, README.md:12-14
Summary
The BT Speaker CI pipeline provides automated verification of the monorepo through Melos-driven scripts. By integrating static analysis, formatting checks, and conditional test execution, the pipeline ensures that shared models in bt_speaker_core and application logic in pi_app remain stable. The use of GitHub Actions with coverage reporting to Codecov provides visibility into the health of the project as it moves toward full deployment on Raspberry Pi hardware.
Sources: README.md:46-52, CLAUDE.md:80-83