For non-web platforms, `flutter drive` is deprecated. This switches those platforms from `flutter drive` to `flutter test`. This makes the logic to check for test driver files web-specific, since `flutter test` doesn't require a driver.
Removes support for the legacy test-in-test_driver-directory structure, which is no longer used anywhere in the repository.
Also includes a minor drive-by fix to the way we do process output, noticed while manually testing. Instead of adding all stdout, and only then adding all stderr, this adds both then waits for both, which should allow interleaving of stdout and stderr in the terminal.
Fixes https://github.com/flutter/flutter/issues/105634
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
It can be useful in debugging snippet setup to look at the extraction output, but the tool cleans that up automatically. Running the extraction manually is complicated due to the on-the-fly pubspec modifications, so this adds a `--no-cleanup` flag that can be used to skip the deletion of the extraction output, and instead log its location to the terminal.
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
The instructions for `format` failures still referred to using `activate`, which is no longer how tools are invoked. Replace the specific instructions with a link to the relevant README section to make them evergreen.
Adds aliases for all commands that put the verb first, since currently they are inconsistent which can make it hard to remember (in particular, I often write `check-foo` instead of `foo-check` when running locally, and it fails).
Also does the long-overdue renaming of `test` to `dart-test`, since we now have `native-test`, `custom-test`, etc. `test` continues to work as an alias for individual muscle memory.
Updates `update-excerpts` to support any top-level .md file (other than CHANGELOG.md), rather than just README.md. This is useful for supplemental content, such as migration guides linked from the main README file.
Also makes some small improvements to the error messaging:
- The list of incorrect files is now relative to, and restricted to, the package. This makes the error message simpler, and ensures that changed files in other packages don't get listed.
- Adds a link to the relevant wiki docs, since this has been a source of confusion for newer contributors.
The change to how the repository is located assumed the script was being
run from bin/flutter_plugin_tools.dart, but it can also be run directly
from lib/src/main.dart which was broken. This restores the ability to
run it either way.
Fixes the tree breakage in `release`.
Now that the repo tooling is always run from source, not via `pub global`, we no longer need to infer the repo location from the current directory. Instead, hard-code knowledge of where the repository root is. This makes it much easier to run the tooling, since it's common to be in a package directory rather than the repo root.
To make it even easier to run from within a package, this also adds a `--current-package` as an alternative to `--packages`. This makes it possible to, e.g., write local wrapper scripts that run a specific set of commands on whatever the current package happens to be (such as a generic version of the script discussed in https://github.com/flutter/packages/pull/4129).
As related cleanup, makes the tool non-publishable (we haven't been publishing it since the repo merge, but I never made it unpublishable; this is important now that it would not work if published) and remove the LICENSE and CHANGELOG since it's no longer a stand-alone package.
Fixes https://github.com/flutter/flutter/issues/128231
Fixes https://github.com/flutter/flutter/issues/128232
Currently we are running Dart unit tests in Chrome for any plugin with
web support, but it should only be necessary for plugins that have an
inline web implementation, not for app-facing packages that endorse a
web implementation.
The `http` package was updated to 1.0. There are no change that affect our usage (it just adds new class restrictions), so this extends all dependencies to include both 0.13.x and 1.x.
All changes here are tool-applied (`update-dependencies` and `update-release-info`) except for the script/tools/ pubspec update, so are identical in all packages.
Fixes https://github.com/flutter/flutter/issues/127926
This option had been disabled to match flutter/flutter, but the reason it was disabled there was "too many false positives", mostly around animation. That doesn't apply to most packages here, and we've had a number of production bugsâespecially in plugins, that use async heavily in ways that are intended to be client-awaitableâthat this would have caught.
This PR:
- Enables the option at the repo level.
- Permanently (unless the owners decide to change it) opts out `animations` and `go_router`, both of which looked like mostly or entirely false positives.
- Temporarily opted out a few plugins that have a lot of violations that should be handled in their own PRs later (`camera_android_camerax`, most of `webview_flutter`).
- Fixes all remaining violations.
In many cases this PR is behavior-changing, replacing implicitly unawaited futures that did not seem obviously intentional with `await`ed futures, so non-test code in particular should be reviewed carefully to make sure the changes are correct. All of the changes are manual, not `fix`-generated.
Part of https://github.com/flutter/flutter/issues/127323
Removes `unnecessary_null_comparison: ignore` from the repository analysis options. Now that Dart 3 has reached the stable channel, all fully supported customers will be running in strong mode, so the extra null checks are no longer needed. While many packages do support earlier versions, this won't break anyone, it will just mean that people who are both a) using old versions of Flutter and b) violating the API contract by passing null to a non-nullable type, won't get error messages that are as obvious, which is fine for the best-effort support level we give to pre-current-stable versions of Flutter.
Adds the ability to replace portions of the `flutter create`d app with saved copies, and adds a second build-all phase for Android that uses a Flutter 2.0.6-created `android/` directory (AGP 4.1, Gradle 6.7) to catch issues like https://github.com/flutter/flutter/issues/125621 and https://github.com/flutter/flutter/issues/125482 prior to release.
Includes some incidental cleanup:
- Extracts a helper method for adjusting files, so that this doesn't add even more copies of basically identical code.
- (This was motivated by an earlier version of the PR that added modifications to several more files, which I ended up undoing, but the cleanup seemed worth keeping.)
- Adds missing unit test coverage.
- Reworks the unit tests to use a mock process manager and dummy files, instead of each test actually calling `flutter create`, which made each new test add several seconds to the unit test suite.
- While this reduces the integration-style coverage, in practice the integration tests of the repo tooling is the CI itself, so the unit tests should be true unit tests.
- Changes the non-legacy test to Kotlin; we were still testing with Java even though Kotlin has been the default for quite a while, so we weren't testing what most new users would actually be running. Since we now have a legacy test, I used Java there to cover both.
- Removes some dead code for modifying the AndroidManifest.xml; when trying to set up unit tests for it I discovered that it no longer matches anything in an actual project. It dates back to the original command, and seems to have been a camera-related hack, which we clearly no longer need since it wasn't working and camera still works in build-all.
This is captured somewhat in the README in the legacy project directory, but to document the approach here: originally I was going to add flags to change individual items (AGP version, Gradle version), but quickly ran into the fact that selective downgrading is extremely fragile. E.g.,:
- The Kotlin version set in current projects doesn't work when downgrading AGP and Gradle.
- The app template can unconditionally use anything (e.g., `namespace`) that the AGP version it uses supports, so arbitrary future breakage is possible.
It's also less useful as a real test of what a plugin client's project likely looks like. Starting with a complete platform directory, and doing whatever the minimal changes are to keep it working, will likely reflect a common real-world scenario. On the flip side, the reason this doesn't use a complete 2.0.6 project, but instead is based on specific platform directories, is that we don't want to waste time manually maintaining, e.g., old Dart code that is irrelevant to the goal of the test. For now this only uses Android because that's where we've seen problems in practice, but we can alway add other legacy platform tests later if we find a need.
Fixes https://github.com/flutter/flutter/issues/125689
Because we treat analysis warnings as errors, there are common cases where non-breaking changes to part of a federated plugin (adding an enum value, deprecating a method, etc.) are CI-breaking for us. Currently we can't ignore those issues in the same PR where they are added, because doing so would violate the federated saftey check, adding extra complexity to those PRs.
This improves the change detection logic for the federated safety check to ignore comment-only changes in Dart code, which should allow us to add temporary `// ignore:`s in the PRs that create the need for them.
Fixes https://github.com/flutter/flutter/issues/122390
- 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.
https://github.com/flutter/packages/pull/3973 caused an out-of-band
failure after publishing, because an example that uses `url_launcher`
had a too-old Kotlin version set. This is not something we consider
client-breaking because `flutter` prodives a very clear error message
with a straightforward and actionable fix step (update the app's Kotlin
version), so the fix for the breakage is just to update our own
examples.
Since increasingly we're likely to hit problems where modern version of
dependencies don't work with old version of Kotlin, this adds repo-wide
CI enforcement that examples are set to a minimum version (matching the
current `flutter/flutter` template; we can increase this over time as we
feel it's useful to do so).
- Adds a LUCI version of the Linux repo tools test, as a first test of a Linux repository test being migrated to LUCI.
- Fixes the Windows repo tools test to actually run a test, which it wasn't due to a mistaken duplicate yaml file, only one of which was correct (the one that wasn't being used).
Updates version-related checks for the 3.10 release:
- Updates the N-1 and N-2 tests to 3.3 and 3.7.
- Updates the minimum allowed SDK to declare support for to 3.3, matching our test matrix
- Updates all packages that were supporting <3.3 to 3.3 (and equivalent Dart versions for non-Flutter packages)
- Adds a Flutter->Dart mapping for 3.10 in the repo tooling.
Instead of running all test targets in the transitive dependency tree when running Android native unit tests via `gradlew`, specifically target the example app and the containing plugin. This avoids running tests from other packages (such as `flutter_plugin_android_lifecycle`).
Fixes https://github.com/flutter/flutter/issues/85057
When writing pub credentials, ensure that the target paths exists before
trying to write the file. In the past this would have worked because the
credentials were in the pub cache, and the pub cache would exist by the
time the repo tooling code was running. The new location, however, is a
configuration directory that is unlikely to exist before anything
involving `pub` credentials has run.
Should fix the latest `release` failure:
https://github.com/flutter/packages/actions/runs/4949005383/jobs/8854219784
As of Dart 3.0 (Flutter 3.10), the location that the tool was using for
the pub cache wasn't being read, breaking autopublish in CI. This
updates to the new location, and adds tests for it.
Should fix the fact that the `release` step hangs on every package
change now.
When making dependencies path-based using
`--target-dependencies-with-non-breaking-updates`, there was an edge case where a non-breaking change would cause breaking updates in packages that weren't on the latest version of the target. E.g., this happened when updating Pigeon from 9.0.0 to 9.0.1 and there were still packages using Pigeon 4.x-8.x.
Since the purpose of that flag is to find cases (particularly where we use it in CI) where publishing package B would break package A, we don't want to apply it in cases where the new version of B wouldn't be picked up by A anyway.
This adds filtering on a per-package level when in this mode, which validates that the on-disk package version is within the referencing package's constraint range before adding an override.
Fixes https://github.com/flutter/flutter/issues/121246
https://github.com/flutter/flutter/issues/125707
- Create pluginTools config for every example that shrunk material icons and had an android config
Likely some build caching but before/after If someone knows how to clean the cache or force a rebuild I will give more accurate after numbers.
Command
`time dart run ./script/tool/bin/flutter_plugin_tools.dart build-examples --apk`
Secondary validation from @stuartmorgan who discovered this is between a 10% and 25% speed increase.
Existing tests add confidence this is non-breaking. New tests not required because these are optional flags. Validation this does not change is low consequence. Test update to exclude these config files from changelog requirements.
The recent change to add `namespace` to all plugins broke builds for apps using AGP 4.1 or earlier. This conditionalizes setting the namespace based on whether the property exists at all, making it compatible with both AGP 8.0 and AGP <4.2.
Updates tooling to enforce this for plugin (but not example app) build.gradle files.
Fixes https://github.com/flutter/flutter/issues/125621
While current docs about `targetCompatibility` say that it defaults to `sourceCompatibility`, for older toolchains (AGP?) that is apparently not the case, and it's a build error to set `sourceCompatibility` without `targetCompatibility`.
This adds enforcement that it's set to `gradle-check`, and fixes all of the violations.
Fixes https://github.com/flutter/flutter/issues/125482
Moves the checks for Android warning configuration from `lint-android`, where it made sense to put them at the time, to the new `check-gradle`, which is a newer command specifically for validating that our Gradle files are following best practices.
Makes minor changes to the Pigeon platform test projects to make them conform to the checks, since they are now included in the run. The changes shouldn't actually change the behavior of the Pigeon tests.
Adds a `namespace` attribute to the Android build.gradle, for compatibility with Android Gradle Plugin 8.0, and adds tooling to enforce that it's there.
This is necessary for plugins now; for examples this isn't needed yet, but since it will be needed to eventually update the apps to AGP 8.0 anyway, it's easiest to just enforce it everywhere now.
Improves the way we specify and test the `GoogleMaps` SDK dependency on iOS. Currently as discussed in https://github.com/flutter/flutter/issues/86820, we are allowing any version of the SDK, and CocoaPods will choose the best version that's compatible with the minimum iOS deployment version of the plugin client's app. However, clients are also subject to future breakage, since any new major SDK version could have compile-time incompatibility with the plugin's wrapping code. We also have no ability to test anything in CI that's newer than the SDK that supports our oldest supported version (currently that's iOS 11, and thus 5.x).
This makes two changes:
- Replaces the single example with N examples, each with a different minimum iOS version, corresponding to each point where the Google Maps SDK has bumped its minimum iOS requirement. Currently (as documented in the new README file)
- The oldest example has all of the current testing.
- The newest example has just XCTests (not integration or XCUITests).
- Intervening examples have no tests.
- Instead of the completely unpinned version, we allow anything up to the next major version (which should be the first one with breaking API changes).
This gives us build coverage of each of the (latest at CI runtime) resolve points that clients can have. We retain the flexibility of allowing clients to get the best version that meets their app's constraints, except that we will need to explicitly test and enable new major versions, so that they won't randomly break clients.
Fixes https://github.com/flutter/flutter/issues/86820
Adds a repo tool command to validate that all plugins set an explicit Java compatibility version, instead of using whatever the local toolchain happens to be (which creates the potential for issues like https://github.com/flutter/flutter/issues/124839 where our CI passes but builds fail for some clients because our default is newer than theirs).
Currently that's all it checks, but we can add any other gradle best practices we want to enforce here in the future.
This also enables the new check in CI, and fixes all the violations it found.
Fixes https://github.com/flutter/flutter/issues/124839
For all Android plugins:
- Enable all warnings for `lint`
- Treat all warnings as errors for `lint`
This significantly increases the scope of issues that we'll catch in CI. To
allow enabling this without having to make tons of fixes first, so that
we get the incremental benefit immediately, this adds new baselines for
all plugins. We can incrementally clean those baselines up over time.
(In practice we haven't prioritized that, but it would be good to start
paying down that technical debt incrementally at some point.)
See https://github.com/flutter/flutter/issues/88011
Improves the `make-deps-path-based` command:
- When adding an override to a package, also adds it to that package's examples. This is needed for integration tests of app-facing packages of federated plugins when adding features to implementation packages, for instance.
- Switches from string-based rewrites to `yaml_edit` to make it more robust (necessary to do the above without major restructuring)
- Improves the auto-added comment since reviewers new to the repository are often confused by the overrides the first time they encounter them and think their inclusion in the PR is a mistake.
Fixes https://github.com/flutter/flutter/issues/111091
As described in https://github.com/flutter/flutter/issues/121684, we currently have inconsistencies between Flutter SDK constraints and Dart SDK constraints; we have often updated only the former. This PR:
1. Adds CI enforcement via the repo tooling that the minimum versions are consistent.
2. Adds a new repo tooling command to update SDK constraints, to help mass-fix all the violations of the new enforcement in step 1 (and for future mass changes, such as when we update our test matrix and mass-drop support for versions that are no longe tested).
- In all cases, the looser constraint was updated to match the more restrictive constraint, such that there's no actual change in what Flutter version any package actually supports.
3. Runs `dart fix --apply` over all changed packages to automatically fix all of the analysis failures caused by step 2 suddenly making all of our packages able to use `super` parameters.
Fixes https://github.com/flutter/flutter/issues/121684
Fixes https://github.com/flutter/flutter/issues/121685
Since our existing `gradlew lint` check doesn't catch all warnings (notably, deprecation warnings, but also others like raw values), this:
- Configures our plugin example apps to enable `-Xlint:all -Werror` for the javac for the plugin project, so that we also get javac lint coverage in CI. This is done in the example app so that it won't affect plugin clients.
- Adds a check to `lint-android` that the example is configured this way, so that we don't forget to set it up when adding new plugins (or re-generating plugin examples from template).
Where it was trivial for me to just fix existing violations, I did so in this PR. For the rest that had violations, I commented out the enabling of the flags, with a TODO. Normally we would do this kind of thing with a `script/configs` file to opt packages out of a new check, but since this is part of an existing check rather than a whole new command, doing it that way would disable `gradlew lint` for those packages as well. Making a whole new command seemed more complex for the long term, so this seemed like the best short term option. We should try to remove as many of these opt-outs as possible ASAP.
Part of https://github.com/flutter/flutter/issues/91868
