The web tests currently all assume to be using the html renderer. `flutter test` previously erroneously was serving files for the HTML renderer by default (which is not the intended behavior). After this was fixed, the tests started running on the CanvasKit renderer and some of them broke. If we are relying on the html renderer, we should explicitly pass it when running `flutter test`
When running `analyze` in a local tree that has done builds, there can be false positives of the "unexpected analysis options" check due to the .symlinks directory making other packages' analysis options show up in the check. This avoids following links to prevent those false positives.
Updates the repo tooling to Dart 3, now that the N-2 version has Dart 3, which allows us to use Dart 3 features (e.g., records) going forward.
To allow the update:
- Removes `break` commands from `switch`es (all done automatically with `dart fix --apply`)
- Replaces mocking of `ProcessResult` with just creating an actual `ProcessResult` since it's a `final` data class and thus can't (but also doesn't need to be) mocked.
`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.
Expand the multiple-test-files workaround in `drive-examples` from macOS to all of the desktop platforms, now that we know it's not macOS-specific.
See https://github.com/flutter/flutter/issues/135673
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.
Use a local web server for the legacy test, just as for the non-legacy version.
Also updates the repo tooling to ensure that this test file is found, so it's run regardless of whether tests are run by directory or by individual path.
Part of https://github.com/flutter/flutter/issues/95420
Reworks Pigeon's CI validation of generated files to support multiple hosts, rather than only Linux, with the ability to set specific languages per host, to allow us to run validation for each language on whatever host it is most convenient to set up a formatter for that language, rather than having to support all languages on Linux.
See discussion in https://github.com/flutter/packages/pull/5928
Part of https://github.com/flutter/flutter/issues/41129
Get ready for a world where `swift-format` is available on the `PATH` https://flutter-review.googlesource.com/c/recipes/+/54020
1. Add `format --clang-format --java --kotlin --swift --dart` flags to decide whether to run specific formatters, as opposed to using the `path`. Keep `swift-format` optional but default the others to run. This matches the current behavior on Linux.
2. Add `*-path` variants of each.
This will allow us to run `format --swift --no-clang-format --no-java --no-kotlin --no-dart` on the macOS bot so it doesn't duplicate same `format` call run on Linux.
Part of https://github.com/flutter/flutter/issues/41129
Now that the latest Flutter stable requires iOS 12, and will auto-adjust projects, we can drop iOS 11 support in this plugin without breaking users. Having a minimum of iOS 12 means that Cocoapods should not resolve to anything older than Google Maps 6.x, which is the version that add arm64 simulator support, so the workaround to explicitly not build that can be removed. This means `google_maps_flutter` will no longer force projects into the buggier Rosetta iOS simulator path.
This folds the iOS 11 and iOS 12 examples together, since (per `examples/README.md`) the iOS 11 version is the one containing most of the tests. To minimize the potential of losing tests due to mistakes, this was done by deleting the iOS *12* example, renaming the iOS 11 example, and then updating it to a minimum of 12.
Fixes https://github.com/flutter/flutter/issues/94491
Adds a new tool command (and runs it in CI) to check that each package:
- is listed correctly in the repo-level README.md table
- has a CODEOWNERS entry
In the future we could add other things (e.g., auto-label), but these were the main things we've had issues with recently.
Updates README.md and CODEOWNERS to fix failures it found:
- Adds a couple of missing CODEOWNERS
- Expands the web implementation CODEOWNERS to individual packages so that we don't have to special-case handling in the tool
- Fixes some minor mistakes in README.md
- URL-encodes all `:`s in the README.md links (which is why ever line shows as changed); it worked without that in practice, but it should really be encoded, and having it consistently encoded made things easier for the tooling.
Adds privacy manifests to all iOS plugins.
While we only *need* to do the plugins listed [here](https://developer.apple.com/support/third-party-SDK-requirements/) for now, the wording of the page:
> The following are commonly used SDKs in apps on the App Store
suggests that the list of things for which this is required is just an arbitrary cutoff rather than a conceptual distinction, so it seems safest to just assume the list will grow over time and do all of them. To ensure that, this includes new repo tooling to check that a manifest is specified in the podspec.
The large caveat is that we do not currently know if this actually works. This is the method of inclusion that seems to be [the consensus among people using Cocoapods](https://github.com/CocoaPods/CocoaPods/issues/10325), as bundling it directly as a `resource` causes problems for clients who do not use `use_frameworks`. (In theory it seems like a manifest would not actually be *required* in that case since there is no framework, but it has the potential to actually stomp top-level resources.) Hopefully the automated analysis that Apple will eventually roll out will tolerate the file being bundled in a resource bundle in the framework rather than a top-level manifest file. If not, however, it's not clear how Cocoapods can be supported, so we can adopt this common approach for now under the assumption that eventually tooling will adapt to the reality of the ecosystem, and revisit the exact bundling later if necessary.
Only `shared_preferences` has a non-empty manifest, as it is our only plugin that uses a required reason API, and none of our plugins themselves collect private data. Ideally for that plugin we would instead use `C56D.1`, which is for wrappers, but as currently written we can't use it since it's exclusively a wrapper. If that changes in the future based on our pending request, we can revisit. For now, however, this reason should suffice since we don't currently allow reading from other app groups.
Fixes https://github.com/flutter/flutter/issues/131495
Fixes https://github.com/flutter/flutter/issues/139756
Fixes https://github.com/flutter/flutter/issues/139757
Fixes https://github.com/flutter/flutter/issues/139758
Fixes https://github.com/flutter/flutter/issues/139759
Fixes https://github.com/flutter/flutter/issues/139760
See also https://github.com/flutter/flutter/issues/139761
For iOS and macOS move fetch deps from explicity running `pub get` and `pod install` to instead run `flutter build x --config-only` which smartly fetches deps and lays down the required native pieces. I didn't guard it on whether certain files are present since the command already has similar guards, and runs pretty fast if the native code has already been generated.
This fixes an issue where `pod install` is run before the Flutter native bits and migrations are run.
Fixes issues seen in the Flutter roll https://github.com/flutter/packages/pull/5792#issuecomment-1876103613
```
Running command: "pod install" in /Volumes/Work/s/w/ir/x/w/packages/packages/camera/camera_avfoundation/example/ios
Analyzing dependencies
[!] CocoaPods could not find compatible versions for pod "Flutter":
In Podfile:
Flutter (from `Flutter`)
Specs satisfying the `Flutter (from `Flutter`)` dependency were found, but they required a higher minimum deployment target.
[!] Automatically assigning platform `iOS` with version `11.0` on target `Runner` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`.
Unable to "pod install"
```
Caused by https://github.com/flutter/flutter/pull/140478
A non-Flutter package can have Flutter-based tests (e.g., cupertino_icons), in which case we need to use `flutter test` rather than `dart test` just like we would for a package with a non-dev Flutter dependency. This updates the `requiresFlutter` check to include dev dependencies as well as normal dependencies.
⦠to `update-excerpts` tool
Need this tool to recognize `.java`, `.gradle`, and `.sh` files in order to complete [flutter/flutter#102679](https://github.com/flutter/flutter/issues/102679). The `README.md` for the `espresso` package contains code from `.java`, `.gradle`, and `.sh` files.
Support for `.m` files was requested by @tarrinneal.
Part of fix for https://github.com/flutter/flutter/issues/138336 by bumping the Gradle version of all package example apps (plus `image_picker_android` plugin) to 7.6.3 from those that had a version below that to fix security vulnerability.
Also fixes a bug I found while using the `update-dependencies` packages tool command that caused it to not catch all of the `gradle-wrapper.properties` files when running with the `gradle` dependency + added a test for the fix.
The update-min-sdk command has been using explicitly ranges for the Dart
SDK, because that used to be required. Current versions of `pub` no
longer require that, and using `^` for Dart ranges is okay, so this
updates the tooling to use that format in the future.
Also removes the special casing that changed the upper bound from 3 to
4, since we have passed the point where we are generating upper bounds
less than 4 anyway.
To minimize churn, this doesn't update the existing pubspecs. We can
incrementally adopt this going forward as we roll dependencies forward.
Fixes https://github.com/flutter/flutter/issues/139806
Updates the tooling to fetch and use `ktfmt` for Kotlin code, the same way it currently does for the Google Java formatter, and applies that formatting (in the default mode; see discussion in the linked issue) to the repository.
In the future we could revisit the formatter or mode, but since this currently seems to be the most consistent with our other languages and to google3 formatting this is likely the option we'll want to stick with.
Fixes https://github.com/flutter/flutter/issues/118756
This tweaks the errors messages that provide info like how to override a repo check for versioning or changelog updates.
Basically added newlines, so the errors do not require scrolling far off to the right to get the message.
Adds support for swift-format in the `format` command. For now this is optional, so is only triggered if the flag is explictly passed. In the future, once we have CI support for swift-format, we will likely want to make it on-by-default as with the other formatters.
Part of https://github.com/flutter/flutter/issues/41129
`filter-packages-to` didn't correctly the handle the case where the set of target packages is empty, meaning that all packages should be tested. This broke it for cases such as changing a CI configuration file, making the filter not take effect.
Endorses the macOS implementation of `video_player`, updating the constraint of the existing `video_player_avfoundation` dependency to ensure macOS support is present. Adds macOS support to the example, and adds macOS discussion to the README.
This is the first macOS plugin with multiple integration test files, which turned up a bug in `flutter test`, so this also includes a repo tooling change to work around that bug for now by running each integration test file separately on macOS (as we already have to do with `flutter drive` on web).
Fixes https://github.com/flutter/flutter/issues/41688
The Flutter build process creates podspecs that are just shims pointing to the local Flutter framework, and which don't pass the linter since they aren't intended for publishing. When finding podspecs to lint, skip those.
This avoids incorrect failures when running on a tree that isn't clean (in particular, where macOS and/or iOS builds have happened), which is very common locally.
Creates a package filter flag that is an opt-in mirror to the `exclude` flag, for use with the automatic package selection options used in CI. Like `exclude`, it allows for YAML files as input.
This allows for creating split test runs in CI (e.g., during incremental migrations), where the same file is an inclusion filter for one run and an exclusion filter for the other, guaranteeing that tests are in one or the other without the possibility of some tests falling through the cracks.
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
