Flutter: Selective CI Checks
Has your Flutter project already reached the stage when Continuous Integration (CI) pipelines require optimization to save both time and money? Well, there are a bunch of approaches for optimization, one of which is selective CI checks.
Since you are looking for ways to optimize your CI, the odds are you have a sizeable project and may already use a Monorepo.
In this article, I showed a clean small monorepo conveying the idea of dealing with Flutter app modularization. I’ll use the same repository here to share a way to implement selective CI checks.
Full CI Checks Setup
First, let’s implement some basic CI checks.
For the Counter App in my repository, which consists of 5 modules and uses Melos to manage the monorepo, I used the following CI checks in the basic Github Workflow.
Each of the CI steps outlined in the above workflow executes for each of the five modules in the monorepo. This isn’t the most efficient use of resources as not every pull request involves changes to all the modules. Therefore, there’s space for improvement!
Selective CI Checks Setup
The concept behind selective CI checks is to only validate the segments of code that are relevant or impacted by a specific change, such as a pull request. Methods like git diff or path filters can be employed.
For Flutter Monorepos that use Melos, the Melos Diff Filter is a handy tool, especially when combined with IncludeDependends Filter. Utilizing the command melos list --diff=origin/main..HEAD --include-dependends, we can obtain a list of packages that have changed compared to the main branch, as well as their dependents. Afterward, we can set the filter list into melos_packages variable which will act as a global scope for all the melos commands. Here comes the corresponding workflow.
Selective CI Checks In Action
For the sake of the example I opened a tiny PR with a change in data module to show that the Selective CI checks will run only on it and on app module because it depends on data.
The following screenshot illustrates the significant difference in resource allocation, which is quite noticeable even for such a small repository. Just think of the substantial improvement potentially achievable on a production project with hundreds, or even thousands, of tests and other CI checks!
Conclusion
Verifying everything with every code change is inefficient, particularly for large projects. The act of optimizing is a delicate balance of efficiency, cost, and performance. By implementing the right strategy, you can achieve significant improvements in your CI pipelines.
