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.
The error summary for a CHANGELOG validation failure was written when
the only thing being checked was that the versions matched, but now
there are other ways to fail as well (i.e., leaving NEXT). This fixes
the summary message to be more generic so that it doesn't mislead people
who hit validation failures.
While adding the test for this message, I discovered that almost all of
the tests were actually talking to pub.dev, causing their behavior to in
some cases depend on whether a package with that name happened to have
been published, and if so what its version was. In order to make the
tests hermetic and predictable, this fixes that by making all tests use
a mock HTTP client.
Replaces the use of an actual git repository on the filesystem with mock git output and an in-memory filesystem.
This:
- makes the tests more hermetic.
- simplifies the setup of some tests considerably, avoiding the need to run the command once to set up the expected state before running a second time for the intended test.
- eliminates some of the special handling in the test's custom process runner (making it easier to eliminate in a PR that will follow after).
Also adds some output checking in a couple of tests that didn't have enough to ensure that they were necessarily testing the right thing (e.g., testing that a specific thing didn't happen, but not checking that the publish step that could have caused that thing to happen even ran at all).
Finishes the migration of tool tests to `runCapturingPrint`. This makes
the tests much less verbose, and makes it match the rest of the tool
tests.
Also adds the use of `printError` for error output, now that it's
trivial to do so.
Packages are the primary conceptual object in the tool, but currently they are represented simply as Directory (or occasionally a path string). This introduces an object for packages and:
- moves a number of existing utility methods into it
- sweeps the code for the obvious cases of using `Directory` to represent a package, especially in method signatures and migrates them
- notes a few places where we should migrate later, to avoid ballooning the size of the PR
There are no doubt other cases not caught in the sweep, but this gives us a foundation both for new code, and to migrate incrementally toward as we find existing code that was missed.
The mock process runner used in most of the tests had poor handling of
stdout/stderr:
- By default it would return the `List<int>` output from the mock
process, which was never correct since the parent process runner
interface always sets encodings, thus the `dynamic` should always be
of type `String`
- The process for setting output on a `MockProcess` was awkward, since
it was based on a `Stream<Lint<int>>`, even though in every case what
we actually want to do is just set the full output to a string.
- A hack was at some point added (presumably due to the above issues)
to bypass that flow at the process runner level, and instead return a
`String` set there. That meant there were two ways of setting output
(one of which that only worked for one of the ways of running
processes)
- That hack wasn't updated when the ability to return multiple mock
processes instead of a single global mock process was added, so the
API was even more confusing, and there was no way to set different
output for different processes.
This changes the test APIs so that:
- `MockProcess` takes stdout and stderr as strings, and internally
manages converting them to a `Stream<List<int>>`.
- `RecordingProcessRunner` correctly decodes and returns the output
streams when constructing a process result.
It also removes the resultStdout and resultStderr hacks, as well as the
legacy `processToReturn` API, and converts all uses to the new
structure, which is both simpler to use, and clearly associates output
with specific processes.
Ensures that the full relative path in the 'repository' link is correct,
not just the last segment. This ensure that path-level errors (e.g.,
linking to the group directory rather than the package itself for
app-facing packages) are caught.
Also fixes the errors that this improved check catches, including
several cases where a previously unfederated package wasn't fixed when
it was moved to a subdirectory.
The federated plugin spec calls for implementation packages to include an `implements` entry in the `plugins` section of the `pubspec.yaml` indicating what app-facing package it implements. Most of the described behaviors of the `flutter` tool aren't implemented yet, and the pub.dev features have `default_plugin` as a backstop, so we haven't noticed that they are mostly missing (or in one case, incorrect).
To better future-proof the plugins, and to provide a better example to people looking at our plugins as examples of federation, this adds a CI check to make sure that we are correctly adding it, and fixes all of the missing/incorrect values it turned up.
Fixes https://github.com/flutter/flutter/issues/88222
Adds a new `lint-android` command to run `gradlew lint` on Android plugins.
Also standardizes the names of the Cirrus tasks that run all the build and platform-specific (i.e., not Dart unit test) tests for each platform, as they were getting unnecessarily long and complex in some cases.
Fixes https://github.com/flutter/flutter/issues/87071
Adds integration test support for Android to `native-test`. Also fixes
an issue where the existing unit test support was not honoring
`--no-unit`.
Fixes https://github.com/flutter/flutter/issues/86490
The special "NEXT" entry in a CHANGELOG should never be present in a
commit that bumped the version. This validates that this is true even if
the CHANGELOG would be correct for a non-version-change state, to catch
someone incorrectly resolving a merge conflict by leaving both parts of
the conflict, rather than folding the 'NEXT' entry's list into the new
version's notes.
Fixes https://github.com/flutter/flutter/issues/85584
Removes the `build_all_plugins_app.sh` bash script, in support of the goal of eliminating all use of bash from the repository (for maintainability, and for better Windows compatibility).
- The exclusion list moves to a config file, match other recent repo changes
- The exclusion logging moves into the tool itself, consistent with the tool doing more logging of skipped and excluded plugins
- The bulk of the logic moves to a Cirrus task template. This was done instead of rewriting the script in Dart, even though it will mean more work for alternate CI support (e.g., bringing this up on a Windows LUCI bot), because breaking it into components makes it easier to pinpoint failures from the CI UI rather than having all the steps smashed together.
Makes commands that use the package-looping base command track and
report exclusions. This will make it much easier to debug/audit
situations where tests aren't running when expected (e.g., when enabling
a new type of test for a package that previously had to be explicitly
excluded from that test to avoid failing for having no tests, but
forgetting to remove the package from the exclusion list).
Also fixes a latent issue with using different exclusion lists on
different commands in a single CI task when using sharding could cause
unexpected failures due to different sets of plugins being included for
each step (e.g., build+drive with an exclude list on drive could
potentially try to drive a plugin that hadn't been built in that shard)
by sharding before filtering out excluded packages.
Adds testing for sharding in general, as there was previously none.
Currently the tool accepts `--custom-analysis` to allow a list of packages for which custom `analysis_options.yaml` are allowed, and `--exclude` to exclude a set of packages when running a command against all, or all changed, packages. This results in these exception lists being embedded into CI configuration files (e.g., .cirrus.yaml) or scripts, which makes them harder to maintain, and harder to re-use in other contexts (local runs, new CI systems).
This adds support for both flags to accept paths to YAML files that contain the lists, so that they can be maintained separately, and with inline comments about the reasons things are on the lists.
Also updates the CI to use this new support, eliminating those lists from `.cirrus.yaml` and `tool_runner.sh`
Fixes https://github.com/flutter/flutter/issues/86799
Creates a new `native-test` command that will be used to run native unit and UI/integration tests for all platforms over time. This replaces both `xctest` and `java-test`.
For CI we can continue to run each platform separately for clarity, but the combined command makes it easier to use (and remember how to use) for local development, as well as avoiding the need to introduce several new commands for desktop testing as support for that is added to the tool.
Fixes https://github.com/flutter/flutter/issues/84392
Fixes https://github.com/flutter/flutter/issues/86489
If a package supports Android, it will now report failure instead of
skip if no tests run. This matches the new behavior of drive-examples,
and is intended to prevent recurrance of situations where we are
silently failing to run tests because of, e.g., tests being in the wrong
directory.
Also fixes a long-standing but unnoticed problem where if a
run tried to run more than one package's tests, it would hang
forever (although on the bots it doesn't seem to time out, just
end logs abruptly) due to a logic error in the call to configure
gcloud.
Fixesflutter/flutter#86732
To prep for making a combined command to run native tests across different platforms, rework `xctest`:
- Split analyze out into a new `xcode-analyze` command:
- Since the analyze step runs a new build over everything with different flags, this is only a small amount slower than the combined version
- This makes the logic easier to follow
- This allows us to meaningfully report skips, to better notice missing tests.
- Add the ability to target specific test bundles (RunnerTests or RunnerUITests)
To share code between the commands, this extracts a new `Xcode` helper class.
Part of https://github.com/flutter/flutter/issues/84392 and https://github.com/flutter/flutter/issues/86489
Currently each type of check handles its output in isolation, which
creates confusing output when the last check succeeds but an earlier
check fails, since the end of the output will just be a success message.
This makes the output follow the same basic approach as the package
looper commands, where all failures are collected, and then a final
summary is presented at the end, so the last message will always reflect
the important details.
It also adopts the colorized output now used by most other commands.
Allows `format` to run successfully on Windows:
- Ensures that no calls exceed the command length limit.
- Allows specifying a `java` path to make it easier to run without a system Java (e.g., by pointing to the `java` binary in an Android Studio installation).
- Adds clear error messages when `java` or `clang-format` is missing since it's very non-obvious what's wrong otherwise.
Bumps the version, which I intended to do in the previous PR but apparently didn't push to the PR.
