macOS 14 added new requirements that un-codesigned sandbox apps must be granted access when changed. Waiting for this UI caused macOS tests to fail on macOS 14. Additionally, adding codesigning is not sufficient, since it must still be approved before codesigning is enough to pass the check. As a workaround, this PR disables sandboxing for macOS tests in CI.
https://developer.apple.com/documentation/updates/security#June-2023)
> App Sandbox now associates your macOS app with its sandbox container using its code signature. The operating system asks the person using your app to grant permission if it tries to access a sandbox container associated with a different app. For more information, see [Accessing files from the macOS App Sandbox](https://developer.apple.com/documentation/security/app_sandbox/accessing_files_from_the_macos_app_sandbox).
And that link explains why this is happening on a macOS 14 update:
> In macOS 14 and later, the operating system uses your appâs code signature to associate it with its sandbox container. If your app tries to access the sandbox container owned by another app, the system asks the person using your app whether to grant access. If the person denies access and your app is already running, then it canât read or write the files in the other appâs sandbox container. If the person denies access while your app is launching and trying to enter the other appâs sandbox container, your app fails to launch.
>
> The operating system also tracks the association between an appâs code signing identity and its sandbox container for helper tools, including launch agents. If a person denies permission for a launch agent to enter its sandbox container and the app fails to start, launchd starts the launch agent again and the operating system re-requests access.
Fixes packages part of https://github.com/flutter/flutter/issues/149264.
Verified tests pass:
https://ci.chromium.org/ui/p/flutter/builders/staging.shadow/Mac_arm64%20macos_platform_tests%20master%20-%20packages/6/overview
Adds the flowing to the tool:
- A new `--exact-match-only` flag to be used with `--packages` to prevent group matching (i.e., a selection like `--packages=path_provider --exact-match-only` would only run on `packages/path_provider/path_provider`, not `packages/path_provider/*`).
- Two new `publish` command flags:
- `--tag-for-auto-publish`, to do all the steps that `publish` currently does except for the real `pub publish`, so it would dry-run the publish and then create and push the tag if successful.
- `--already-tagged`, to skip the step of adding and pushing a tag, and replace it with a check that `HEAD` already has the expected tag.
This set of additions supports a workflow where the current `release` step is changed to use `--tag-for-auto-publish`, and then the separate auto-publish system would publish each package with `... publish --already-tagged --packages=<some package> --exact-match-only`.
See https://github.com/flutter/packages/pull/5005#discussion_r1344542422 for previous discussion/context.
Part of https://github.com/flutter/flutter/issues/126827
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.
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.
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.
`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.
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.
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 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
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
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
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
- 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.
Follow-up to https://github.com/flutter/plugins/pull/7038 to try to make
it work on LUCI. Looking at the checkout steps of a LUCI run, it looks
like we do a full `fetch` of `origin`, but likely only have a `master`
branch locally. Rather than rely on a specific local branch name
existing, this allows for checking `origin` (and just in case, since
it's another common remote name, `upstream`).
Hopefully fixes https://github.com/flutter/flutter/issues/119330
* Standardize on .g.dart
* Remove unused exclusion patterns
* Mark pigeons/ as dev-only in the tooling
* Version bumps
* Add missed files
* More new import fixes
* [tool] Improve main-branch detection
Currently main-branch detection for `--packages-for-branch` looks at
branch names, but this no longer works on LUCI which now seems to be
checking out specific hashes rather than branches. This updates the
behavior so that it will treat any hash that is an ancestor of `main` as
being part of `main`, which should allow post-submit detection to work
under LUCI.
Fixes https://github.com/flutter/flutter/issues/119330
* Fix throw
* Fix typos
* Update comment
Pigeon has an usual test structure since it generates test code to run
in a dummy plugin; add that structure to the list of recognized tests so
that changes to its platform tests won't be flagged by `version-check`.
* Add more options that are in flutter/packages
* Fix unnecessary awaits
* More option alignment
* Add and locally supress avoid_implementing_value_types
* Fix release-info for test-only changes
* Fix update-release-info handling of 'minimal'
* Update release metadata
Improves the logic used to determine whether to require a version and/or CHANGELOG change:
- Removes the requirement that dev-only (e.g., test) changes update the CHANGELOG, since in practice we were essentially always overriding in that case.
- Adds file-level analysis of `build.gradle` files to determine whether they are only changing test dependencies.
- Improves the "is this a published example file" logic to better match pub.dev's logic, to fix some false positives and false negatives (e.g., `rfw`'s `example/<foo>/lib/main.dart` being considered published).
Removes the no-longer-necessary special-case handling of some Dependabot PRs, as well as the PR-description-based system it was built on (and that turned out not to be very useful due to the way `CIRRUS_CHANGE_MESSAGE` actually worked). `build.gradle` analysis should not cover all such cases, and without the need to hard-code them by package name.
The analysis options have gotten behind; this re-syncs to the current state of flutter/flutter. For options that are non-trivial to enable, either because they are non-trivial to fix, or touch a very large number of files, they are locally disabled with clear "LOCAL CHANGE" markers so that it's obvious where we are out of sync. For options that are simple to resolve, they are enabled in the PR.
Part of https://github.com/flutter/flutter/issues/76229
Improve package targeting:
- `--run-on-changed-packages` now includes only changed packages in a federated plugin, not all packages. Include all packages isn't useful since (without changes that would cause them to be included anyway) package dependencies are not path-based between packages.
- `--packages` now allows specifying package names of federated plugins. E.g., `--packages=path_provider_ios` will now work, instead of requiring `--packages=path_provider/path_provider_ios`. The fully qualified form still works as well (and is still needed for app-facing packages to disambiguate from the plugin group).
Fixes https://github.com/flutter/flutter/issues/94618
Adds a new command that adds `dependency_overrides` to any packages in the repository that depend on a list of target packages, including an option to target packages that will publish a non-breaking change in a given diff.
Adds a new CI step that uses the above in conjunction with a new `--run-on-dirty-packages` to adjust the dependencies of anything in the repository that uses a to-be-published package and then re-run analysis on just those packages. This will allow us to catch in presubmit any changes that are not breaking from a semver standpoint, but will break us due to our strict analysis in CI.
Fixes https://github.com/flutter/flutter/issues/89862
