3 notable places I did not migrate.
1. engine/src/flutter/docs/Engine-disk-footprint.md treemaps and what
hash is used for what upload.
1. engine/src/flutter/lib/gpu/pubspec.yaml, I didnt want this pr to
update code that could need to be reverted and I didnt know what to do
to test that publishing would not break or cause a downstream breakage.
1. engine/src/flutter/build/zip_bundle.gni I wasnt sure how to test my
changes.
Reviewers: Please let me know if you want a different link or if you
would prefer something unmodified.
Commits:
- **Replace triage links with equivalents, change pull request to
generic flutter/flutter, replace code search link with equivalent**
- **Change link from flutter/engine to engine folder, modify link text
to team**
- **replace engine repo link with engine folder, replace text repo with
folder**
- **replace engine specific security info with flutter generic**
- **replace engine roller comment with a skia roller equivalent**
- **link to same file in new location**
- **Remove comment that some code lives in flutter/flutter and some in
flutter/engine**
- **Say to bump dart in flutter/flutter without mentioning engine**
- **Replace documentation with new locations**
- **replace code printed comments with new locations**
Partially addresses https://github.com/flutter/flutter/issues/167478
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
Unfortunately `10_google3_bug.yml` comes before `2_bug.yml`.
This changes the name (slightly) of the issue templates based on the
instructions from GitHub on what to do when you have 10+ issue templates
(as a side-note: I wonder if we need/still use umbrella bugs for the
feature tracker, or two types of performance bugs)
🚫 **BLOCKED** : Do not merge until
https://github.com/flutter/flutter/issues/161261 (additional test
coverage).
---
This PR eliminates (1) `scenario_app/android`, and all references to an
Android `scenario_app`, including documentation, CI configuration, build
rules, test runner, Android-side test application, and (2), to verify
and disambiguate the remains, renames the folder `ios_scenario_app`,
which is now accurate.
It also eliminates elements that were _only_ used in the Android-side
scenario_app, such as Firebase Test Lab uploading.
I would be open to doing this in phases if we thought it was better to
do so, but given its mostly a mechanical change (and by renaming the
directory, references can be checked merely by looking for
`/\bscenario_app/`, I believe this is safe to iterate on and eventually
merge after the holidays.
## Background
As of the merged mono-repo, there is no longer a requirement for the
engine to be testable as a standalone unit.
As an example,
[`%ENGINE%/testing/scenario_app`](3762f2e973/engine/src/flutter/testing/scenario_app),
which was intended to _emulate_ the Flutter framework (and some of
`flutter_tools` tooling), load the iOS and Android embedder, and run
various "scenarios" (which ran a combination of `dart:ui` code and
Android Java/iOS Obj-C) verifying golden-file screenshots.
Instead, it is now possible to write and run _real_ (full) Flutter apps
the same way that an end-user (or our own tests) would. One such example
is
[`dev/native_driver_test`](https://github.com/flutter/flutter/tree/master/dev/integration_tests/native_driver_test),
which is a full-fledged Flutter app, which uses standard tooling (i.e.
`flutter`), to test most of the same elements that previously were only
tested in the Android version of `scenario_app`.
I was struggling to get the engine to compile now that it's under the
flutter/flutter monorepo, and I noticed that the wiki docs have not been
updated since the monorepo migration completed. This PR attempts to
update them to give a process that works with the new setup.
I've gone ahead and updated all of the links in the "Engine repo"
section of [the wiki](https://github.com/flutter/flutter/wiki) to point
to the flutter/flutter copies of these docs since they were previously
pointing to the flutter/engine copies.
I tested these instructions by following them myself and successfully
getting the engine changes in
https://github.com/flutter/flutter/pull/161103 to work with the
framework changes in https://github.com/flutter/flutter/pull/159013 on
iOS compiling with `et`.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
AKA "Dude Where's My Files?"
Document the history editing that will occur during the monorepo merge.
`flutter/engine` will remain the source of truth of revisions older than
the merge.
---------
Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
Changed the word "there" to "their" in Flutter GPU doc... which I think is correct, but I could be wrong. Thanks!
- [] I listed at least one issue that this PR fixes in the description above.
- [] I added new tests to check the change I am making or feature I am adding, or the PR is [test-exempt]. See [testing the engine] for instructions on writing and running engine tests.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
As of the following patches, we now bundle FlutterMacOS.framework.dSYM as part of FlutterMacOS.xcframework. The dSYM is automatically copied into the release build products directory, and bundled in the .xcarchive produced by Xcode's *Product > Archive* feature which produces bundles for upload to the App Store.
* https://github.com/flutter/engine/pull/54696
* https://github.com/flutter/flutter/pull/153975
The .dSYM bundle is now available both in the uploaded .xcarchive and in the xcframework in Flutter's internal artifact cache. For developers with CI toolchains that do additional manual handling or local archiving of .dSYMs, the dSYMs no longer need to be downloaded from cloud storage as previously detailed in `docs/Crashes.md`, but can instead be copied up from the appropriate dSYM subdirectory in the framework cache:
* `flutter/bin/cache/artifacts/engine/darwin-x64-release/FlutterMacOS.xcframework`
Also adds documentation for crash symbolication on macOS.
Issue: https://github.com/flutter/flutter/issues/153879
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Rather than editing `.ci.yaml` to enable the `linux_web_engine` shard, instead suggest tagging with the `test: all` label, which avoids the risk of accidentally committing an unwanted change to `.ci.yaml` and having to revert the change before landing.
This is also more future-proof against further `runIf` additions to `.ci.yaml`.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Most framework tests perform a `flutter precache` or rely on the web SDK in some form. The Web SDK is not build in presubmit by default. As such, developers will need to manually comment out the `runIf` conditional block that prevents the web SDK from being built during presubmit, then later hope they uncomment it before landing their patch.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#54453
Not quite ready to remove Impeller Scene yet because I'm still porting
the animation functionality. Keeping it around allows me to switch back
and forth to compare without having to recompile the engine.
Over a month ago I said something like "we can revert this a couple of
weeks from now" in one of the Impeller meetings. But for better or worse
(better, I think), I ended up spending a ton of time trying to make the
PBR good first (which doesn't exist in this C++ version).
This renames the iOS framework creation script for consistency with the analogous macOS script.
Previously, we had two iOS framework creation scripts:
* create_ios_framework.py
* create_full_ios_framework.py
The former was unused and was deleted in https://github.com/flutter/engine/pull/54227. The addition of "full" is no longer necessary to differentiate the two.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
In 2021, we did some experiments with ML-guided optimisations in the
engine. Ultimately, these didn't provide much benefit, and much of the
information in the documentation is now out-of-date.
For those who need it, this can always be found in the git history.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Document that when using RBE, users should ensure the locally installed Xcode toolchain version matches that of the bots, otherwise they're likely to experience slow builds due to cache misses.
Ideally, we should also check the value automatically against the `sdk_version` specified in the relevant `et` build config itself.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR changes from using a different GN pool for each non-compiler tool, to using one GN pool for everything.
Additionally, since we are no longer linking remotely in any configuration, this PR uses the pool for linking.
ObjC and impellerc tasks also do not (yet) run on RBE, so they are also now governed by the pool.
Needs https://github.com/flutter/buildroot/pull/856
