Adds an `android-dependency` option to the `update-dependency` command such that you can update Android dependencies provided the dependency and a version across relevant plugins. This PR specifically adds support for the Gradle dependency, relevant to plugin example apps.
Running the command looks like:
```
dart run script/tool/bin/flutter_plugin_tools.dart update-dependency --android-dependency gradle --version 1.2.3
```
Adds [topics](https://dart.dev/tools/pub/pubspec#topics) to all
packages, supporting the new pub feature for categorizing packages. The
heuristics I used were:
- Try to use existing topics from https://pub.dev/topics where
applicable
- Add new topics as necessary to cover things that seemed like obvious
relevant topics
- Include the plugin name as a topic for all federated plugin packages,
for grouping (since pub doesn't inherently group or cross-link
implementations)
This is not an attempt to be exhaustive; as topics evolve I expect we
will add more or adjust.
Also updates the repo tooling to enforce topics, so that we don't forget
to add them to new packages. The enforced rule is:
- All packages must have at least one topic. We could potentially change
this to allow an empty `topics` section so that we are enforcing that we
didn't just forget to add the section, but in practice even for packages
that we don't expect people to be likely to use, I didn't have any issue
coming up with at least one relevant topic.
- Federated plugin packages must contain the plugin name as a topic.
While this isn't time-critical, I chose to include version bumps so that
we aren't rolling out topics in a piecemeal way (e.g., with only a
random subset of a federated plugin's packages having topics on pub.dev
based on what has happened to have a bugfix).
- Updates the N-1 and N-2 analysis bot configs to 3.7 and 3.10
- Updates the minimum allowed SDK to 3.7, since that's now the earliest we have any testing for.
- Updates all packages to Flutter 3.7/Dart 2.19 as a minimum.
- In packages where we hadn't released since the last minimum version bump, I removed the previous line from the `#NEXT` section to make it less confusing when we do release.
Per https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#version this does not update any package versions.
- Adds artifact hub check to gradle command
- Add tests for build.gradle and settings.gradle check
- Update all example build.gradle and settings.gradle files
flutter/flutter/issues/120119
Expansion of https://github.com/flutter/packages/pull/4567
If adding a pathified dependency creates a resolver error, then skip it instead of failing when running pathified analysis. The purpose of pathified analysis it to pre-detect failures that would happen on publishing, and if there's a resolver error that means the publishing even won't affect the package anyway.
See https://github.com/flutter/packages/pull/4483#issuecomment-1664468621 for an example case where we need this.
(In theory we could get delayed OOB errors that this will missâe.g., in the case above if the PR would actually break rfw/example/wasm, then if at some later date `wasm` updated to use a newer `ffi`, eliminating the resolver conflict, then suddenly rfw/example/wasm would pick up the PR and break. That seems *extremely* unlikely, however, so I'm not concerned that this will be a problem in practice. We can revisit if that changes.)
Adds new LUCI versions of the Android FTL tests. These are new tasks, rather than being part of android_platform_tests, since those are already running the emulator version of the tests, and the combination is far too slow (unless we roughly double the number of shards anyway), and this lets us control the behavior separately (e.g., not running them on `stable`, and potentially making them post-submit only in the future).
Adjusts the repo tooling to make the `gcloud auth` step optional, since that's handled automatically for us in the LUCI environment, and to make it less tightly coupled to the Cirrus configuration by removing those defaults from the tool.
Part of https://github.com/flutter/flutter/issues/114373
See also https://github.com/flutter/flutter/issues/131429
Adds `fetch-deps` support for:
- iOS/macOS dependencies, using `pod install`
- Dart package dependencies, using `pub get`
To make avoid doing extra work in the Dart dependencies step when using this with `*_platform_tests` CI, also adds flags for all of the other platforms, and adds a flag that allows skipping Dart dependencies for any package that doesn't have an example supporting any requested platform. This means that we can pass, e.g., `--windows --supporting-target-platforms-only` to only fetch Dart packages for packages with examples that will be build during the build-and-drive Windows tests.
Adds this as a new step in every platform tests CI task, and in the standard analyze step, so that we will pre-fetch Dart packages (and for iOS/macOS, pods). This won't yet fully eliminate later network access (see https://github.com/flutter/flutter/issues/131204), but will give us early warning on any major failures, such as pub being entirely unreachable from the bots.
- These are marked as an infrastructure step; we'll have to see if this ends up being confusing in practice. If `pub` resolution fails for legitimate reasons, such as a PR that tries to require a version of a package that doesn't exist or that has conflicts, this will cause a failure that is marked as infra. My assumption is that the much more common case is going to be that it is actually an infra failure.
Fixes https://github.com/flutter/flutter/issues/130280
Moves the check that README snippets using code excerpting are up to date to LUCI. Now that the check has been rewritten to be extremely fast, it's folded into the existing repo checks instead of being a separate task.
Also adjusts the tooling slightly so that it logs the count of snippets checked, for auditability in CI, like the old version of the excerpt update tooling did.
Part of https://github.com/flutter/flutter/issues/114373
* Allows excerpts to come from any package, not just examples.
* Fixes a bug in the excerpting logic that was causing a stray `}` to appear in one example.
* Removes the need for `build.excerpt.yaml` files.
* Remove the dependency on build_runner for excerpts.
* Reduces the time to generate the excerpts from about 10 minutes to about 5 seconds.
* Almost certainly fixes https://github.com/flutter/flutter/issues/107180 (untested).
The new logic is not quite backwards compatible; the `path-base` feature now specifies a real path to the actual source directories, rather than a path into the invisible generated `excerpts/` directory with its special structure. Also, a number of features from the previous package that were not actually used in this repository are no longer supported (such as having multiple section names per `#docregion` pragma).
Refactors colorization to a centralized utility file, and makes it all conditional on `stdout` having ANSI escape support. This makes the output more readable on LUCI, which unlike the Cirrus log display doesn't handle ANSI.
Fixes https://github.com/flutter/flutter/issues/89392
Adds new legacy analysis targets to LUCI in bringup mode.
Also updates the repo tooling to use a Flutter->Dart version mapping instead of having to separately maintain a Dart version, now that we already have such a map in the tool anyway.
Part of https://github.com/flutter/flutter/issues/114373
Since the tool only needs to support back to Flutter 3.3 (the oldest version we still run CI with), this updates the tool to the corresponding minimum Dart version.
This allows the use of `super` parameters, so `dart fix --apply` was run to convert them all (and remove all the includes that were only needed for setting default values).
Also opportunistically cleans up a bunch of unnecessary, very old `dart:async` includes. (Other than those removals, the changes here are all `dart fix`-generated.)
Extracts common logic for running `pub get`, and switches commands to use it. The common logic always uses `flutter pub get` for Flutter packages, rather than `dart pub get`, since the latter will fail if someone has a non-Flutter `dart` in their path before `flutter` (e.g., Dart team members contributing PRs).
The new `--current-package` flag was returning `foo` when run in the app-facing package of a federated plugin called `foo`, but `foo` as a package argument is treated as being the entire group, so it was running all for all of the packages in the plugin. This fixes it to return `foo/foo` in that case, which is how the tool targets app-facing packages specifically.
Adds web platform tests for LUCI in bringup mode.
The Cirrus version of the test starts `chromedriver` at the beginning and just leaves it running, which is fine since it's a fresh docker image each run. For LUCI we don't want that behavior though, so instead this adds tooling support for running chromedriver as part of running the integration tests, controllable with a flag. This will also be useful for running locally.
Part of https://github.com/flutter/flutter/issues/114373
Adds an initial Android platform tests LUCI script, and initial targets in bringup mode (using 6 shards instead of the 8 we have in Cirrus since the added shards were to try to address what in retrospect was likely a device availability issue, and since for now this will be running fewer tests; once everything is migrated we can evaluate whether we need more shards).
Rather than wait for emulator and/or FTL support in LUCI to do the migration of this target, this will partially migrate; the script currently does only the parts that don't require any kind of device. That will let us set up a baseline of LUCI Android platform tests bots to easily expand from as we figure out those pieces, and we can turn down these parts of the tests in Cirrus once these come out of bringup mode to minimize duplication.
To avoid having to run a full `flutter build` for both versions, this also updates the repo tooling to use the new `flutter build apk --config-only` option to create `gradlew` without doing a full build.
Part of https://github.com/flutter/flutter/issues/114373
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.
