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.
The purpose of this PR is to make running all unit tests on Windows pass (vs failing a large portion of the tests as currently happens). This does not mean that the commands actually work when run on Windows, or that Windows support is tested, only that it's possible to actually run the tests themselves. This is prep for actually supporting parts of the tool on Windows in future PRs.
Major changes:
- Make the tests significantly more hermetic:
- Make almost all tools take a `Platform` constructor argument that can be used to inject a mock platform to control what OS the command acts like it is running on under test.
- Add a path `Context` object to the base command, whose style matches the `Platform`, and use that almost everywhere instead of the top-level `path` functions.
- In cases where Posix behavior is always required (such as parsing `git` output), explicitly use the `posix` context object for `path` functions.
- Start laying the groundwork for actual Windows support:
- Replace all uses of `flutter` as a command with a getter that returns `flutter` or `flutter.bat` as appropriate.
- For user messages that include relative paths, use a helper that always uses Posix-style relative paths for consistent output.
This bumps the version since quite a few changes have built up, and having a cut point before starting to make more changes to the commands to support Windows seems like a good idea.
Part of https://github.com/flutter/flutter/issues/86113
- Adds unit tests, as there are currently none.
- Adds more graceful failure handling.
- Adds an internal ignore list to skip files that don't need to be
formatted that showed up during local testing.
- Adds a note explaining that it's intentially not using the new base
command due to performance issues.
Makes validating that there are no unexpected analysis_options.yaml
files part of the per-package loop, rather than a pre-check, so that it
only runs against the target packages. This makes it easier to run
locally on specific packages, since it's not necessary to pass the allow
list for every package when targetting just one package.
* [flutter_plugin_tools] Work around banner in drive-examples
Strip off any unexpected output before parsing `flutter devices
--machine` output. Works around a bug in the Flutter tool that can
result in banners being printed in `--machine` mode.
Fixes https://github.com/flutter/flutter/issues/86052
Migrates `test` to the new package looping base command.
Refactors the bulk of the logic to helpers for easier understanding of the flow.
Part of flutter/flutter#83413
Most of the tool operates on packages in general, and the targetting
done currently by the `--plugins` flag is not actually restricted to
plugins, so this makes the name less confusing.
Part of https://github.com/flutter/flutter/issues/83413
Many commands had insufficient failure testing. This adds new tests that
ensure that for every Process call, at least one test fails if a failure
from that process were ignored (with the exception of calls in the
`publish` command, which has a custom process mocking system, so was out
of scope here; it already has more coverage than most tests did though.)
For a few existing failure tests, adds output checks to ensure that they
are testing for the *right* failures.
Other changes:
- Adds convenience constructors to MockProcess for the common cases of a
mock process that just exits with a 0 or 1 status, to reduce test
verbosity.
- Fixes a few bugs that were found by the new tests.
- Minor test cleanup, especially cases where a mock process was being
set up just to make all calls succeed, which is the default as of
recent changes.
To support this command's --machine flag, which moves all normal output into a field in a JSON struct, adds a way of capturing output and providing it to the command subclass on completion.
Part of flutter/flutter#83413
The intent of package-looping commands is that we always want to run them for all the targeted packages, accumulating failures, and then report them all at the end, so we don't end up with the problem of only finding errors one at a time. However, some of them were using `exitOnError: true` for the underlying commands, causing the first error to be fatal to the test.
This PR:
- Removes all use of `exitOnError: true` from the package-looping commands. (It's still used in `format`, but fixing that is a larger issue, and less important due to the way `format` is currently structured.)
- Fixes the mock process runner used in our tests to correctly simulate `exitOrError: true`; the fact that it didn't was hiding this problem in test (e.g., `drive-examples` had a test that asserted that all failures were summarized correctly, which passed because in tests it was behaving as if `exitOnError` were false)
- Adjusts the mock process runner to allow setting a list of mock result for a specific executable instead of one result for all calls to anything, in order to fix some tests that were broken by the two changes above and unfixable without this (e.g., a test of a command that had been calling one executable with `exitOnError: true` then another with ``exitOnError: false`, where the test was asserting things about the second call failing, which only worked because the first call's failure wasn't actually checked). To limit the scope of the PR, the old method of setting a single result for all calls is still supported for now as a fallback.
- Fixes the fact that the mock `run` and `runAndStream` had opposite default exit code behavior when no mock process was set (since that caused me a lot of confusion while fixing the above until I figured it out).
- Updates the remaining tests (other than one that still needs to be
converted to the new base command, which will be fixed then) that
aren't using runCapturingPrint to do so to reduce test log spam.
- Simplifies and standardizes the matcher used for ToolExit in tests.
Add a summary to the end of successful runs for everything using the new looping base command, similar to what we do for summarizing failures. This will make it easy to manually check results for PRs that we know should be changing the set of run packages (adding a new package, adding a new test type to a package, adding a new test type to the tool), as well as spot-checking when we see unexpected results (e.g., looking back and why a PR didn't fail CI when we discover that it should have).
To support better surfacing skips, this restructures the return value of `runForPackage` to have "skip" as one of the options. As a result of it being a return value, packages that used `printSkip` to indicate that *parts* of the command were being skipped have been changed to no longer do that.
Fixes https://github.com/flutter/flutter/issues/85626
Significantly restructures drive-examples:
- Migrates it to the new package-looping base command
- Enforces that only one platform is passed, since in practice multiple platforms never actually worked. (The logic is structured so that it will be easy to enable multi-platform if `flutter drive` gains multi-platform support.)
- Fixes the issue where `--ios` and `--android` were semi-broken, by doing explicit device targeting for them rather than relying on the default device being the right kind
- Extracts much of the logic to helpers so it's easier to understand the flow
- Removes support for a legacy integration test file structure that is no longer used
- Adds more test coverage; previously no failure cases were actually tested.
Fixes https://github.com/flutter/flutter/issues/85147
Part of https://github.com/flutter/flutter/issues/83413
Migrates firebase-test-lab to use the new package-looping base command.
Other changes:
- Extracts several helpers to make the main flow easier to follow
- Removes support for finding and running `*_e2e.dart` files, since we no longer use that file structure for integration tests.
Part of https://github.com/flutter/flutter/issues/83413
Switches build-examples to the new base command that handles the boilerplate of looping over target packages.
While modifying the command, also does some minor cleanup:
- Extracts a helper to reduce duplicated details of calling `flutter build`
- Switches the flag for iOS to `--ios` rather than `--ipa` since `ios` is what is actually passed to the build command
- iOS no longer defaults to on, so that it behaves like all the other platform flags
- Passing no platform flags is now an error rather than a silent pass, to ensure that we never accidentally have CI doing a no-op run without noticing.
- Rewords the logging slightly for the versions where the label for what is being built is a platform, not an artifact (which is now everything but Android).
Part of flutter/flutter#83413
Combines the two different aspects of version-checking into a single looping structure based on plugins, using the new base command, rather than one operating on plugins as controlled by the usual flags and the other operating on a git list of changed files.
Also simplifies the determination of the new version by simply checking the file, rather than querying git for the HEAD state of the file. Tests setup is simplified since we no longer need to set up nearly as much fake `git` output.
Minor changes to base commands:
- Move indentation up to PackageLoopingCommand so that it is consistent across commands
- Add a new post-loop command for any cleanup, which is needed by version-check
- Change the way the GitDir instance is managed by the base PluginCommand, so that it's always cached even when not overridden, to reduce duplicate work and code.
Part of https://github.com/flutter/flutter/issues/83413
Switches `java-test` to the new base command that handles the boilerplate of looping over target packages.
Includes test improvements:
- Adds failure tests; previously no failure cases were covered.
- Captures output so test output isn't spammed with command output.
Part of flutter/flutter#83413
Switches `podspec` to the new base command that handles the boilerplate of looping over target packages.
Includes test improvements:
- Adds failure tests; previously no failure cases were covered.
- Captures output using the standard mechanism instead of using a custom
`_print`, simplifying the command code.
Also removes `--skip`, which is redundant with `--exclude`.
Part of flutter/flutter#83413
Switches `analyze` to the new base command that handles the boilerplate
of looping over target packages. This will change the output format
slightly, but shoudn't have any functional change.
Updates tests to use runCapturingPrint so that test run output isn't
mixed with command output.
Part of https://github.com/flutter/flutter/issues/83413
This PR removes a TODO where we used to check if a release should happen against git tags, instead, we check against pub.
Also, when auto-publish and the package is manually released, the CI will continue to fail without this change.
Fixesflutter/flutter#81047
Most of our commands are generally of the form:
```
for (each plugin as defined by the tool flags)
check some things for success or failure
print a summary all of the failing things
exit non-zero if anything failed
```
Currently all that logic not consistent, having been at various points copied and pasted around, modified, in some cases rewritten. There's unnecessary boilerplate in each new command, and there's unnecessary variation that makes it harder both to maintain the tool, and to consume the test output:
- There's no standard format for separating each plugin's run to search within a log
- There's no standard format for the summary at the end
- In some cases commands have been written to ToolExit on failure, which means we don't actually get the rest of the runs
This makes a new base class for commands that follow this structure to use, with shared code for all the common bits. This makes it harder to accidentally write new commands incorrectly, easier to maintain the code, and lets us standardize output so that searching within large logs will be easier.
This ports two commands over as a proof of concept to demonstrate that it works; more will be converted in follow-ups.
Related to https://github.com/flutter/flutter/issues/83413
Rather than taking a list of list of path elements, just accept a list
of Posix-style paths. In practice, the API was already being partially
used that way.
common.dart is a large-and-growing file containing all shared code,
which makes it hard to navigate. To make maintenance easier, this splits
the file (and its test file) into separate files for each major
component or category.
Migrates publish-check and version-check commands to NNBD.
Reworks the version-check flow so that it's more consistent with the other commands: instead of immediately exiting on failure, it checks all plugins, gathers failures, and summarizes all failures at the end. This ensures that we don't have failures in one package temporarily masked by failures in another, so PRs don't need to go through as many check cycles.
Part of https://github.com/flutter/flutter/issues/81912
- Adds macOS support to the `xctest` tool command
- Adds logic to the tool to check for packages that delegate their implementations
to another package, so they can be skipped when running native unit tests
- Updates the tool's unit test utility for writing pubspecs to be able to make
delegated federated implementation references to test it
- Adds initial unit tests to the non-deprecated macOS plugins
- Enables macOS XCTesting in CI
macOS portion of https://github.com/flutter/flutter/issues/82445
Migrates:
- `all_plugins_app`
- `podspecs`
- `firebase-test-lab`
Minor functional changes to `firebase-test-lab` based on issues highlighted by the migration:
- The build ID used in the path is now a) passable, and b) given a fallback value in the path that
isn't "null"
- Flag setup will no longer assume that `$HOME` must be set in the environment.
- Adds a --build-id flag to `firebase-test-lab` instead of hard-coding the use of `CIRRUS_BUILD_ID`.
The default is still `CIRRUS_BUILD_ID` so no CI changes are needed.
Part of https://github.com/flutter/flutter/issues/81912
Eliminates the global test filesystem and global test packages directory, in favor of local versions. This guarantees that each test runs with a clean filesystem state, rather than relying on cleanup. It also simplifies understanding the tests, since everything is done via params and return values instead of needing to know about the magic global variables and which methods mutate them.
- Replaces most explicit use of `fileSystem` with path construction using the `child*` utility methods
- Removes explicit passing of a filesystem to the commands; we're already passing a `Directory` for the
root where the tool operates, and we should never be using a different filesystem than that directory's
filesystem, so passing it was both redundant, and a potential source of test bugs.
- Removes the .cirrus.yml workaround that removed macOS podspecs before linting
- Deletes the dummy macOS podspecs that are no longer needed due to `flutter` fixes
- Adds --use-modular-headers to the lint command to reflect what Flutter Podfiles do
- Fix the actual issues in the podspecs
