`script/tool_runner.sh` has only been intended for CI usage for quite a while, but it still lives in a prominent non-CI location which has been a source of confusion for developers (e.g., people looking at how CI is running things, and reasonably assuming that since the script isn't in a CI-specific location, it's for general use). While running it for simple cases works, it conflicts with any package selection, which is common thing to want to control when running locally.
This makes the following changes:
- Move the script into the .ci directory
- Adds explicit comments that it's not designed for local use, with a pointer to the corresponding local command
- Removes a stale reference to external-to-the-repo use of tool_runner.sh, as that usage no longer exists
- Also consolidates and updates the links to the external scripts
- Updates a couple of CONTRIBUTING.md comments that still said to run tool_runner.sh
- Opportunistically cleans up some tooling references to .cirrus.yml, found while cleaning up comments in tool_runner.sh and checking for other references.
The example app of a federated example is effectively test-only code, so treat changes to it (other than the one published file) as dev-only for the purposes of deciding what to flag for CHANGELOGs.
Adds new LUCI targets in bringup mode to run all possible Dart unit tests in Chrome.
This is a new test (see linked issue), not a port of a Cirrus test, so it involves changes to tooling and packages:
- The tooling now accepts an explicit platform. The default behavior if none is provided is the previous behavior of running in VM for everything but web plugin implementations (since that's convenient locally).
- The tooling now has a basic understanding of `dart_test.yaml` `test_on` directives, to know when to skip.
- Packages that don't support web have opt-out files.
- Packages that do support web but have a few tests that fail on web have those tests opted out.
- Packages that do support web but have a lot of failures on web have temporary opt-out files with TODOs + issue links.
Most of https://github.com/flutter/flutter/issues/128979
Updates the state checker to inspect changed Dart files to see if the only changes are implementation (not documentation) comment lines. In particular, this will fix the problem of CI flagging changes that do nothing but add `// ignore:` comments (for federated package changes involving deprecation, framework changes that require temporary ignores in packages to support stable, etc.) as needing version and changelog changes
- Updates all macOS plugins to 10.14 as a minimum version, matching Flutter `stable`.
- Checks in the results of building all macOS examples with stable to bring them up to current with auto-migrations (and in some cases, with having ever been built, in the case of some examples with plugins where the CocoaPods changes were never committed).
All Runner.xcodeproj and Runner.xcworkspace changes are 100% tool-generated.
Also updates the repo tooling to know about a few more build-only example files that should not be flagged as potentially interesting for changelogs.
* Standardize on .g.dart
* Remove unused exclusion patterns
* Mark pigeons/ as dev-only in the tooling
* Version bumps
* Add missed files
* More new import fixes
Pigeon has an usual test structure since it generates test code to run
in a dummy plugin; add that structure to the list of recognized tests so
that changes to its platform tests won't be flagged by `version-check`.
Improves the logic used to determine whether to require a version and/or CHANGELOG change:
- Removes the requirement that dev-only (e.g., test) changes update the CHANGELOG, since in practice we were essentially always overriding in that case.
- Adds file-level analysis of `build.gradle` files to determine whether they are only changing test dependencies.
- Improves the "is this a published example file" logic to better match pub.dev's logic, to fix some false positives and false negatives (e.g., `rfw`'s `example/<foo>/lib/main.dart` being considered published).
Removes the no-longer-necessary special-case handling of some Dependabot PRs, as well as the PR-description-based system it was built on (and that turned out not to be very useful due to the way `CIRRUS_CHANGE_MESSAGE` actually worked). `build.gradle` analysis should not cover all such cases, and without the need to hard-code them by package name.
