This directory exists to support building Flutter on our build infrastructure.
The results of such builds are viewable at:
The Chromium infra bots do not allow forcing new builds from outside the Google network. Contact @eseidelGoogle or another Google member of the Flutter team if you need to do that.
The Cirrus-based bots run the
test.dart script for each PR and submission. This does testing for the tools, for the framework, and (for submitted changes only) rebuilds and updates the master branch API docs staging site. For tagged dev and beta builds, it also builds and deploys the gallery app to the app stores. It is configured by the .cirrus.yml.
We also have post-commit testing with actual devices, in what we call our devicelab.
This part of our infrastructure is broken into two parts. A buildbot master specified by our builders.pyl file, and a set of recipes which we run on that master. Both of these technologies are highly specific to Google‘s Chromium project. We’re just borrowing some of their infrastructure.
To work on this infrastructure you will need:
sudo apt-get install python-pip
sudo pip install coverage
To run prepare_package.dart locally:
python %DEPOT_TOOLS%\gsutil.pyon Windows) to authenticate with your auth token. When asked, the GCP project ID is
dart [path to your normal Flutter repo]/dev/bots/prepare_package.dart --temp_dir=. --revision=[revision to package] --branch=[branch to deploy to] --publish.
The following will get way more than just recipe code, but it will get the recipe code:
mkdir chrome_infra cd chrome_infra fetch infra
More detailed instructions can be found here.
Most of the functionality for recipes comes from
recipe_modules, which are unfortunately spread to many separate repositories. After checking out the code search for files named
The typical cycle for editing a recipe is:
build/scripts/slave/recipes.py test trainto update existing expected output to match the new output. Verify completely new test cases by altering the
GenTestsmethod of the recipe. The recipe is required to have 100% test coverage.
build/scripts/slave/recipes.py run flutter/<repo> slavename=<slavename> mastername=client.flutter buildername=<buildername> buildnumber=1234where
<repo>is one of
buildernamecan be looked up from the Build Properties section of a recent build.
git checkout -b [some branch name]).
git cl upload) and send it to someone in the
recipes/flutter/OWNERSfile for review.
Flutter uses Chromium's fancy builders.pyl master generation system. Chromium hosts 100s (if not 1000s) of buildbot masters and thus has lots of infrastructure for turning them up and down. Eventually all of buildbot is planned to be replaced by other infrastructure, but for now flutter has its own client.flutter master.
You would need to edit client.flutter's master in order to add slaves (talk to @eseidelGoogle), add builder groups, or to change the html layout of https://build.chromium.org/p/client.flutter. Carefully follow the builders.pyl docs to do so.
We would like to host our own recipes instead of storing them in build. Support for cross-repository recipes is in-progress. If you view the git log of this directory, you‘ll see we initially tried, but it’s not quite ready.
The Android SDK and NDK used by Flutter's Chrome infra bots are stored in Google Cloud. During the build a bot runs the
download_android_tools.py script that downloads the required version of the Android SDK into
To check which components are currently installed, download the current SDK stored in Google Cloud using the
download_android_tools.py script, then
dev/bots/android_tools/sdk/tools/bin/sdkmanager --list. If you find that some components need to be updated or installed, follow the steps below:
Run Android SDK Manager and update packages
$ dev/bots/android_tools/sdk/tools/android update sdk Use
android.bat on Windows.
Use the UI to choose the packages you want to install and/or update.
dev/bots/android_tools/sdk/tools/bin/sdkmanager --update. On Windows, run
sdkmanager.bat instead. If the process fails with an error saying that it is unable to move files (Windows makes files and directories read-only when another process is holding them open), make a copy of the
dev/bots/android_tools/sdk/tools directory, run the
sdkmanager.bat from the copy, and use the
--sdk_root option pointing at
dev/bots/android_tools/sdk/tools/bin/sdkmanager --licenses and accept the licenses for the newly installed components. It also helps to run this command a second time and make sure that it prints “All SDK package licenses accepted”.
Run upload_android_tools.py -t sdk
$ dev/bots/upload_android_tools.py -t sdk
Download a new NDK binary (e.g. android-ndk-r10e-linux-x86_64.bin)
$ cd dev/bots/android_tools
Remove the old ndk directory
$ rm -rf ndk
Run the new NDK binary file
Rename the extracted directory to ndk
$ mv android-ndk-r10e ndk
Run upload_android_tools.py -t ndk
$ cd ../..
$ dev/bots/upload_android_tools.py -t ndk
The Flutter codelabs exercise Material Components in the form of a demo application. The code for the codelabs is similar to, but distinct from, the code for the Shrine demo app in Flutter Gallery.
The Flutter codelabs build test ensures that the final version of the Material Components for Flutter Codelabs can be built. This test serves as a smoke test for the Flutter framework and should not fail. If it does, please address any issues in your PR and rerun the test. If you feel that the test failing is not a direct result of changes made in your PR or that breaking this test is absolutely necessary, escalate this issue by submitting an issue to the MDC-Flutter Team.