This sample project allows you to leverage GitHub Actions to run common Flutter workflows. These are based on the workflows found in the Flutter Gallery repository.
Create a workflow .yml file in your .github/workflows directory. Example workflows are available in this repository. For more information, reference the GitHub Help Documentation for Creating a workflow file.
All workflows use the Ensure SHA Pinned Actions action to ensure security hardening.
Note: The Get the Flutter Version Environment action requires that the pubspec.yaml file contains an environment:flutter: key. This is used for installing Flutter in the workflows.
Also known as CI, Continuous Integration runs Flutter static and dynamic tests on every pull request to main, then the coverage report is stored as an artifact for reference. Modify the workflow to further process the code coverage file using code quality or code review actions.
.github/workflows/cdelivery.yml
Also known as CDelivery (not to be mistaken with another CD, Continuous Deployment), Continuous Delivery reruns the same Flutter static and dynamic tests from the CI on every push to main, then a pre-release draft is created. Manually, remove the pre-release mark after it has been deployed and released to the app store.
.github/workflows/deployment.yml
Deployment is triggered when the release draft is published. It reruns the same Flutter static and dynamic tests from the CI before running Flutter's build commands. The app version used is based on the release tag, not the name. Lastly, build artifacts are uploaded as release assets.
The scripts and documentation in this project are released under the MIT License