Until https://github.com/flutter/flutter/issues/172427 is resolved, `xcode-analyze` doesn't work as desired with SwiftPM enabled (it analyzes only the test code, not the plugin code). To avoid losing analysis coverage in the meantime, this disabled SwiftPM temporarily while running analysis.
This PR also updates `build-examples` to use the newer pubspec-based config option to set the SwiftPM flag state instead of setting global state, to avoid future issues where we are unintentionally bleeding flag changes across different tests, and to make local runs not impact developer machine state.
To unit test this functionality, this adds a new feature to the existing process mock system that allows running an arbitrary test callback at the ponit where a process is being run, which in this case allows reading the temporarily-modified pubspec contents at the right point in the command execution.
Fixes https://github.com/flutter/flutter/issues/171442
## Pre-Review Checklist
**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.
[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.
First attempt at an AGENTS.md file to make Jules more effective at
creating PRs.
I started with an initial draft, then iterated based on feedback from
Gemini Code Assist, taking most of its suggestions (under the theory
that it has more examples of AGENTS.md files in its model than I do),
but removing some hallucinations.
I was going to put the "Agent Environment Setup" in a separate file, so
that people could manually add it to their Jules configuration, but
Gemini found that file and thought it should be in AGENTS.md. I'm
curious to see if that will work well enough that we don't each need to
do the manual one-time configuration. If it doesn't work, we can move it
later.
🤷🏻
Adds initial file-based filtering. This does not attempt to be comprehensive, just to get some low-hanging fruit, and to create a blueprint for anyone to follow in the future when adding more filtering. I expect that once this is in place, what will happen is that as we notice cases where PRs are hitting slow or flaky tests that they clearly don't need to, we can incrementally improve the filtering on demand.
Fixes https://github.com/flutter/flutter/issues/136394
Currently xcode-analyze relies on the native project files already having been generated. This is unreliably locally, and now is problematic on CI as well since Xcode builds now (as of https://github.com/flutter/flutter/pull/165916) must match the last build mode, so analysis will fail if the previous CI step built in release mode (as is currently the case).
This adds a config-only build call in debug mode before analyzing. Since running a config-only build is a common operation in the tool, this extracts a helper to abstract the logic.
Unblocks the flutter/flutter->flutter/packages roller.
Consolidates the code to find all changed file paths into the `PackageLoopingCommand` class that is the base of almost all of the repo tooling commands. This in a preparatory PR for a future change to allow each command to define a list of files or file patterns that definitively *don't* affect that test, so that CI can be smarter about what tests to run (e.g., not running expensive integration tests for README changes).
A side effect of this change is that tests of almost all commands now need a mock `GitDir` instance. This would add a lot of copy/pasted boilerplate to the test setup, and there is already too much of that, so instead this refactors common test setup:
- Creating a memory file system
- Populating it with a packages directory
- Creating a RecordingProcessRunner to mock out process calls
- Creating a mock GitDir that forwards to a RecordingProcessRunner
into a helper method (using records and destructuring to easily return multiple values). While some tests don't need all of these steps, those that don't can easily ignore parts of it, and it will make it much easier to update tests in the future if they need them, and it makes the setup much more consistent which makes it easier to reason about test setup in general.
Prep for https://github.com/flutter/flutter/issues/136394
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
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.
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
