So far we've been using the default mode of prevailing-in-file, which
means we aren't consistent within each language what mode we use. Now
that clang-format can identify ObjC headers (which didn't used to be the
case), we can enforce different styles for the two languages.
This sets left-aligned for C++ to match the Flutter engine, and
right-aligned for ObjC to match the prevaling Apple style.
Switches the web tests from using the version of Chrome installed by the Dockerfile, which is whatever happened to be stable when the image is generated, and thus not hermetic, to a pinned version of Chromium. This uses a slightly modified version of the script that is already used for flutter/packages.
Since Chromium doesn't support mp4 playback, this updates the `video_player` integration tests to use WebM on web instead, to avoid having all the tests fail in CI.
Part of https://github.com/flutter/flutter/issues/84712
Currently the flake situation for Firebase Test Lab tests is very bad,
and the task running those tests are some of the slowest tasks in the
CI. Re-running failed tests is slow, manual work that is signficantly
affecting productivity.
There are plans to actually address the flake in the short-to-medium
term, but in the immediate term this will improve the CI situation, as
well as reducing the drag on engineering time that could be spent on the
root causes.
Part of https://github.com/flutter/flutter/issues/95063
Improve package targeting:
- `--run-on-changed-packages` now includes only changed packages in a federated plugin, not all packages. Include all packages isn't useful since (without changes that would cause them to be included anyway) package dependencies are not path-based between packages.
- `--packages` now allows specifying package names of federated plugins. E.g., `--packages=path_provider_ios` will now work, instead of requiring `--packages=path_provider/path_provider_ios`. The fully qualified form still works as well (and is still needed for app-facing packages to disambiguate from the plugin group).
Fixes https://github.com/flutter/flutter/issues/94618
This removes all of the deprecated plugins from the tree, as well as all references to them.
They were being left in the tree only in case they needed critical fixes before the end of this year, when they will become completely unsupported and be officially discontinued on pub.dev. The end of the year is now close enough that such a release is extremely unlikely, and they are causing some maintenance burden (e.g., the tree is currently closed on an out-of-band failure in android_alarm_manager). In the event that we do have to push an emergency fix in the next several weeks, we can either temporarily restore the plugin from git history, or use a branch.
Minor related cleanup:
- Scanning the repository for remaining references turned up that `image_picker_for_web` and `video_player_for_web` had copypasta'd the package name of its example application from one of the deprecated plugins, so this fixes those names.
- Fixes `federation-safety-check` handling of top-level files in unfederated plugins that accidentally tripped federated plugin heuristics.
- Fixes `federation-safety-check` handling of deleted plugins, as it was crashing, and tests that.
- Fixes `make-deps-path-based` handling of deleted plugins, as it was crashing, and tests that.
Adds a new command that adds `dependency_overrides` to any packages in the repository that depend on a list of target packages, including an option to target packages that will publish a non-breaking change in a given diff.
Adds a new CI step that uses the above in conjunction with a new `--run-on-dirty-packages` to adjust the dependencies of anything in the repository that uses a to-be-published package and then re-run analysis on just those packages. This will allow us to catch in presubmit any changes that are not breaking from a semver standpoint, but will break us due to our strict analysis in CI.
Fixes https://github.com/flutter/flutter/issues/89862
When running via Firebase Test Lab, ensure that there is a test using
`FlutterTestRunner`. This ensures that a plugin can't silently not run
any of the Dart integration test on Android by having some other native
integration test.
Fixes https://github.com/flutter/flutter/issues/93952
The currently documented repository policy is to:
- require version updates for packages changes that don't meet specific exemptions, and
- require CHANGELOG changes for essentially all changes.
This adds tooling that enforces that policy, with a mechanism for overriding it via PR descriptions, to avoid cases where they are accidentally omitted without reviewers catching it.
In order to facilitate testing (which require mocking another `git` command), this also updates the existing `version-check` tests:
- Replaces the custom git result injection/validating with the newer bind-to-process-mocks approach that is now used in the rest of the tool tests.
- Fixes some tests that were only checking for `ToolExit` to also check the error output, in order to ensure that failure tests are not accidentally passing for the wrong reason (as is being done in general as tests in the tooling are updated).
Fixes https://github.com/flutter/flutter/issues/93790
Adds a `--log-timing` flag that can be passed to cause package-looping
commands to log relative start time and per-package elapsed time, to
help with future efforts to improve CI times (e.g., finding unusually
slow packages, or designing changes to sharding).
Adds this flag to the CI scripts to enable timing there.
Treat `main` the same as `master` for branch-based switching, in
preparation for switching the branch names in Flutter repositories.
Also updates all of the tests that used `master` as the explicit base to
use `main` instead; what the tests use is arbitrary, so they can be
switched now even though the repo itself hasn't switched.
Part of https://github.com/flutter/flutter/issues/90476
The repository check always failed when run on Windows, because the
relative path generated to check the end of the URL was using local
filesystem style for separators, but URLs always use POSIX separators.
pub.dev deducts points for having a pubspec.yaml `description` that is too short or too long; several of our plugins are losing points on this. To ensure that we are following—and modeling—best practices, this adds a check that our `description` fields meet pub.dev expectations.
Fixes our existing violations. Two are not published even though this only takes effect once published:
- camera: We change this plugin pretty frequently, so this should go out soon without adding a release just for this trivial issue.
- wifi_info_flutter: This is deprecated, so we don't plan to release it. It has to be fixed to allow the tool change to land though.
The license check overlooked Kotlin, since it's not currently widely
used in our repositories.
Also adds the missing license to one Kotlin file, from an example that
was (likely accidentally) re-generated using Kotlin instead of Java.
Adds a check to `publish-check` that there is an AUTHORS file present,
since our license refers to "The Flutter Authors", so we want to have a
file distributed with each package that says who the AUTHORS are (vs.
just having a top-level repo AUTHORS file, which is not part of package
distribution).
Adds AUTHORS files to packages that have been created since the
earlier one-time fix that added them, but didn't add a check to prevent
future issues.
Also updates the publish-check failure tests to include checks for
specific output so that we know that they are failing for the reasons
the test is expecting, bringing them up to current repo standards for
failure tests.
Fixes https://github.com/flutter/flutter/issues/89680
The new safety check doesn't allow simple platform-interface-only
changes because it doesn't actually check that a non-interface package
is actually modified before failing it for a modified platform
interface.
This fixes that, and adds a test case covering it.
Creates a new command to validate that PRs don't change platform interface packages and implementations at the same time, to try to prevent ecosystem-breaking changes. See https://github.com/flutter/flutter/issues/89518 for context.
Per the explanation in the issue, this has carve-outs for:
- Changes to platform interfaces that aren't published (allowing for past uses cases such as making a substantive change to an implementation, and making minor adjustments to comments in the PI package based on those changes).
- Things that look like bulk changes (e.g., a mass change to account for a new lint rule)
Fixes https://github.com/flutter/flutter/issues/89518
Brings iOS and macOS into alignment with the other platforms, where
having unit tests set up is required.
- For deprecated plugins with no tests, `--exclude`s them, as on other platforms.
- For `quick_actions` and `share`, which have integration tests but no unit tests,
sets up the unit test scaffolding. (This is done for `share` even though it's
deprecated since unlike other platforms, iOS/macOS runs both native tests in the
same command, and setting up a special way to exclude just units tests for that
one case would be much more effort.)
Fixesflutter/flutter#85469
This commit:
* uses the zIndex attribute when converting Circle geometry objects.
* ensures that the getScreenCoordinate method works as expected on the web platform.
* adds tests that can use a fully-rendered Google Map (see projection_test.dart)
* changes the initialization flow of the web Google Map, so the Controller is only returned to the main plugin when it's ready to work.
In order to test the getScreenCoordinate method, the Controller of a fully-rendered map must be available on the test, so we can retrieve information from an actual map instance. While working on this, it was observed that the Controller was being sent to the programmer before it was truly ready (while the map was still initializing).
Instead of littering the test with imprecise timeouts that may make these tests slower (and flakier) than needed, this PR also changes the initialization process of a GMap slightly so when its Controller is returned to the user of the plugin (onPlatformViewCreated method call), it is truly ready.
For this:
* Controller.init is immediately called after the controller is created,
* The plugin waits for the first onTilesloaded event coming from the JS SDK, and then
* The Controller is sent to the user
This change happens within "private" sections of the plugin, so programmers using the plugin "normally" shouldn't notice any difference whatsoever (only that the GMap might load slightly faster, and the onPlatformViewCreated callback might be firing a few hundred milliseconds later).
This brings the native Android unit tests in line with the policy of having tests that we expect all plugins to have—unless there's a very specific reason to opt them out—fail when missing instead of skipping when missing, to help guard against errors where we silently fail to run tests we think we are running.
Adds an explicit exclusion list covering the plugins that have a reason to be opted out.
Android portion of flutter/flutter#85469
- Adds a minimal unit test to url_launcher_linux as a proof of concept. This uses almost exactly the same CMake structure as the Windows version that was added recently.
- Adds Linux support for unit tests to `native-test`, sharing almost all of the existing Windows codepath.
- Fixes the fact that it it was running the debug version of the unit tests, but `build-examples` only builds release. (On other platforms we run debug unit tests, but on those platforms the test command internally builds the requested unit tests, so the mismatch doesn't matter.)
- Enables the new test in CI.
Also opportunistically fixes some documentation in `native_test_command.dart` that wasn't updated as more platform support was added.
Linux portion of https://github.com/flutter/flutter/issues/82445
The build-examples command was filtering what it attempted to build by plugin platform, which means it never does anything for non-plugin packages. flutter/packages has steps that run this command, which suggests it used to work and regressed at some point, but nobody noticed; this will re-enable those builds so that we are getting CI coverage that the examples in flutter/packages build.
Mostly fixes https://github.com/flutter/flutter/issues/88435 (needs a flutter/packages tool pin roll to pick this up)
Moves `publish` to PackageLoopingCommand, giving it the same
standardized output and summary that is used by most other commands in
the tool.
Adds minor new functionality to the base command to allow it to handle
the specific needs of publish:
- Allows fully customizing the set of packages to loop over, to support
--all-changed
- Allows customization of a few more strings so the output better
matches the functionality (e.g., using 'published' instead of 'ran' in
the summary lines).
Fixes https://github.com/flutter/flutter/issues/83413
Eliminates the remaining logic from tool_runner.sh, completing the goal of migrating repository tooling off of bash (both to make maintenance easier, and to better support Windows both locally and in CI). Its branch-based logic is now part of the tool itself, via a new `--packages-for-branch` flag (which is hidden in help since it's only useful for CI).
Part of https://github.com/flutter/flutter/issues/86113
Implements support for `--windows` in `native-test`, for unit tests only. The structure of the new code has most of the new functionality in a generic utility for running GoogleTest test binaries, so that it can be trivially extended to Linux support in a follow-up once the Linux test PoC has landed.
This runs the recently-added `url_launcher_windows` unit test. However, it's not yet run in CI since it needs LUCI bringup; that will be done one this support is in place.
Requires new logic to check if a plugin contains native code, and some new test utility plumbing to generate plugins whose pubspecs indicate that they only contain Dart code to test it, to allow filtering filtering out the FFI-based Windows plugins.
Part of flutter/flutter#82445
Replaces the `publish`-command-specific `--package` flag with support for `--packages`, and unifies the flow with the existing looping for `--all-changed`.
This better aligns the command's API with the rest of the commands, and reduces divergence in the two flows (e.g., `--package` would attempt to publish and fail if the package was already published, whereas now using `--packages` will use the flow that pre-checks against `pub.dev`). It also sets up a structure that will allow easily converting it to the new base package looping command that most other commands now use, which will be done in a follow-up.
Since all calls now attempt to contact `pub.dev`, the tests have been adjusted to always mock the HTTP client so they will be hermetic.
Part of https://github.com/flutter/flutter/issues/83413
We never want a plugin to be published without tagging the release, so there's no reason to support the added complexity of these flags. Similarly, once someone has confirmed publishing, we don't want to give them an opt-out for doing the tag.
This allows building UWP plugin examples with `build-examples --winuwp`. As with previous pre-stable-template desktop support, this avoids the issue of unstable app templates by running `flutter create` on the fly before trying to build, so a template that will bitrot doesn't need to be checked in.
Also adds no-op "support" for `drive-examples --winuwp`, with warnings about it not doing anything. This is to handle the fact that the LUCI recipe is shared between Win32 and UWP, and didn't conditionalize `drive`. Rather than change that, then change it back later, this just adds the no-op support now (since changing the tooling is much easier than changing LUCI recipes currently).
This required some supporting tool changes:
- Adds the ability to check for the new platform variants in a pubspec
- Adds the ability to write test pubspecs that include variants, for testing
Part of https://github.com/flutter/flutter/issues/82817
Replaces almost all of the `TestProcessRunner`, which was specific to the `publish` tests, with the repo-standard `RecordingProcessRunner` (which now has most of the capabilities these tests need). This finishes aligning these tests with the rest of the repository tests, so they will be easier to maintain as part of the overall repository.
To support this, `RecordingProcessRunner` was modified slightly to return a succeeding, no-output process by default for `start`. That makes it consistent with its existing `run` behavior, so is a good change in general.
