This directory exists to support building Flutter on our build infrastructure.
Flutter build results are available at:
Flutter infra requires special permissions to retrigger builds on the build dashboard. File an infra ticket to request permission.
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.
The build dashboard includes post-commit testing run on physical devices. See //dev/devicelab for more information.
A set of infra scripts run on Windows, Linux, and Mac machines. The configuration for how many machines and what kind are managed internally by Google. File an infra ticket to request new machine types to be added. Both of these technologies are highly specific to the LUCI project, which is the successor to Chromium's infra and the foundation to Flutter's infrastructure.
To work on this infrastructure you will need:
sudo apt-get install python-pip
sudo pip install coverage
depot_toolsis in your
PATH. If you're on Windows, you also need an environment variable called
DEPOT_TOOLSwith the path to
python3 %DEPOT_TOOLS%\gsutil.pyon Windows) to authenticate with your auth token.
dart [path to your normal Flutter repo]/dev/bots/prepare_package.dart --temp_dir=. --revision=[revision to package] --branch=[branch to deploy to] --publish.
gsutilpermission issues, check with @Hixie to make sure you have the right push permissions.
Flutter has several recipes depending on the test. The recipes share
common actions through
recipe_modules. Searching the
builder config in infra
will indicate the recipe used for a test.
Recipes are just Python with some limitations on what can be imported. They are documented by the luci/recipes-py GitHub project.
The typical cycle for editing a recipe is:
git clone https://flutter.googlesource.com/recipes.
recipes.py test trainto update the 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.
led get-builder 'luci.flutter.staging:BUILDER_NAME' | led edit -p 'revision="GIT_HASH"' | led edit-recipe-bundle | led launch, where
BUILDER_NAMEis the builder name (e.g.
Linux Engine), and
GIT_HASHis the hash to build (which is important for the engine but not for the framework).
ledfails, ensure that your
depot_toolscheckout is up to date.
git checkout -b [some branch name]).
git cl upload), and open the outputted URL to the CL.
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.
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
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.
Flutter downloadable archives are built for each release by our
continuous integration systems using the
script, but if something goes very wrong, and a release is published
that wasn't intended to be published, the
script may be used to remove the package or packages from the channels
in which they were published.
For example To remove a published package corresponding to the git
d444a455de87a2e40b7f576dc12ffd9ab82fd491, first do a
dry run of the script to see what it will do:
$ dart ./unpublish_package.dart --temp_dir=/tmp/foo --revision d444a455de87a2e40b7f576dc12ffd9ab82fd491
And once you've verified the output of the dry run to be sure it is what you want to do, run:
$ dart ./unpublish_package.dart --confirm --temp_dir=/tmp/foo --revision d444a455de87a2e40b7f576dc12ffd9ab82fd491
and it will perform the actions. You will of course need to have
access to the cloud storage server and have
installed to perform this operation. Only runs on Linux or macOS
dart ./unpublish_package.dart --help for more
Once the package is unpublished, it will not be available from the website for download, and will not be rebuilt (even though there is a tagged revision in the repo still) unless someone forces the packaging build to run again at that revision to rebuild the package.