It's no longer a "bit of a hack", it's just a permanent hack ;) (We look for branches with recent commits instead)
2.3 KiB
Experimental Branches
flutter.dev/to/experimental-branches
Cocoon has experimental support for so-called experimental branches in the
flutter/flutter repository.
An experimental branch might be used to test newer versions of an operating
system, or make system-wide flag changes that are not yet in the state where
they can land on master, but are too cumbersome to use something like led
for due to how many steps are required.
WARNING: These branches are not officially supported, and if broken, are only considered a P2 (best effort) to fix.
Creating an experimental branch
Any branch on flutter/flutter that is not:
master- a release candidate, i.e. matches
/flutter-\d+\.\d+-candidate\.\d+/ - and supports PRs (i.e. excluding
stableorbeta, or similar)
... is an experimental branch.
To create an experimental branch, fork an existing branch (i.e. master), and
update both //.ci.yaml and //engine/src/flutter/.ci.yaml so that the root
enabled_targets: [ ... ] includes your branch title, and (recommended) remove
targets not applicable to your experiment.
For an example, see https://github.com/flutter/flutter/pull/168860.
NOTE: New targets are not supported, that is, target names must exist already at tip-of-tree in the
masterbranch.
Testing and Submitting PRs
PRs made against an experimental branch will work similar to the master
channel:
- If needed, the engine is built
- Tests are run against the newly or previously built engine
Submitting a PR works similar to a release-candidate branch in that no merge queue is used.
Once a PR is submitted, it will show up on the Dashboard at a specific URL:
https://flutter-dashboard.appspot.com/#/build?repo=flutter&branch=<BRANCH_NAME>.
The engine is then built and uploaded to GCS, and every test is automatically marked as skipped.
Manually, tests can be scheduled against a sucessfully built engine. Either click the individual test, and hit "re-run", or, for supported branches, use the "Run all tasks" feature to schedule every task for the commit to be run asynchronously (typically a few minutes, though may take longer when postsubmit queues are under load):