Delete and update stale documentation regarding engine/engine hash. (#164324)
This is intended to be merged _after_ https://github.com/flutter/flutter/pull/164317.
This commit is contained in:
Matan Lurey
GitHub
parent
a19509c6c3
commit
3ab49e7d9a
@ -1,66 +1,39 @@
|
||||
# Autorollers
|
||||
|
||||
Several of our dependencies are automatically rolled (updated) by bots.
|
||||
|
||||
## Clang to Engine
|
||||
<img src="https://media1.tenor.com/m/8WV-qfNTVRMAAAAd/autobots-rollout-cat.gif" height="200" />
|
||||
|
||||
We use an auto-roller for Clang on [Linux](https://autoroll.skia.org/r/clang-linux-flutter-engine) and [macOS](https://autoroll.skia.org/r/clang-mac-flutter-engine) (Windows is pending availability of a Windows Clang package from the Fuchsia infra team). In case of build failures or other errors, ping the #hackers-engine channel on [Discord](../contributing/Chat.md).
|
||||
## Clang
|
||||
|
||||
We use an auto-roller for Clang <https://autoroll.skia.org/r/clang-flutter>.
|
||||
|
||||
These rollers may fail if Clang catches a new compilation warning or error that it previously did not, or if a test relies on undefined behavior that has now changed in the new revision of Clang. It is best to resolve such issues ASAP to let the rollers continue and avoid a pile up of issues to resolve.
|
||||
|
||||
The rollers work by updating a [CIPD](https://chrome-infra-packages.appspot.com/p/fuchsia/third_party/clang/) package version in the DEPS file. You can map from a CIPD version to a git revision by checking in CIPD.
|
||||
The rollers work by updating a [CIPD](https://chrome-infra-packages.appspot.com/p/fuchsia/third_party/clang/) package version in the [DEPS](../../DEPS) file. You can map from a CIPD version to a git revision by checking in CIPD.
|
||||
|
||||
## Fuchsia SDK to Engine
|
||||
|
||||
We use an auto-roller for the Fuchsia SDK on [Linux](https://autoroll.skia.org/r/fuchsia-linux-sdk-flutter-engine) and [macOS](https://autoroll.skia.org/r/fuchsia-mac-sdk-flutter-engine) (Windows is pending availability of a Windows Fuchsia SDK package from the Fuchsia infra team). In case of build failures or other errors, ping the #hackers-engine channel on [Discord](../contributing/Chat.md).
|
||||
## Fuchsia SDK
|
||||
|
||||
We use an auto-roller for the Fuchsia SDK on [Linux](https://autoroll.skia.org/r/fuchsia-linux-sdk-flutter)
|
||||
These rollers may fail if the Fuchsia SDK contains a breaking change. It is best to resolve such issues ASAP to let the rollers continue and avoid a pile up of issues to resolve.
|
||||
|
||||
The rollers work by updating a [CIPD](https://chrome-infra-packages.appspot.com/p/fuchsia/sdk/core) package version in the DEPS file. You can map from a CIPD version to a JIRI snapshot or a git revision by checking in CIPD.
|
||||
|
||||
## Skia to Engine
|
||||
## Skia
|
||||
|
||||
We use an auto-roller for Skia rolls. It's status can be viewed at <https://skia-flutter-roll.skia.org/>. In case of build failures or other errors, ping the Flutter-Skia chat channel. In case you get no response, you can log in with an @google.com account and pause the roller (or ask someone with an @google.com account to do so). Please specify a descriptive reason and file a bug to re-enable the rollers as soon as possible.
|
||||
We use an auto-roller for Skia rolls. It's status can be viewed at <https://skia-flutter-roll.skia.org/>. In case of build failures or other errors, ping the Flutter-Skia chat channel. In case you get no response, you can log in with an `@google.com` account and pause the roller (or ask someone with an `@google.com` account to do so). Please specify a descriptive reason and file a bug to re-enable the rollers as soon as possible.
|
||||
|
||||
The bot updates the `skia_revision` line of <https://github.com/flutter/engine/blob/main/DEPS>.
|
||||
The bot updates the `skia_revision` line of [`DEPS`](../../DEPS).
|
||||
|
||||
Skia also uses an auto-roller for Fuchsia; see <https://autoroll-internal.skia.org/r/fuchsia-autoroll>.
|
||||
## Dart
|
||||
|
||||
## Engine to Framework
|
||||
|
||||
The engine is automatically rolled to the framework. It is configured by <https://skia.googlesource.com/skia-autoroll-internal-config.git/+/main/skia-infra-public/flutter-engine-flutter.cfg>.
|
||||
|
||||
The bot updates <https://github.com/flutter/flutter/blob/main/bin/internal/engine.version> to point to the latest revision of the engine *whose artifacts built successfully*, as determined by looking at the [Engine Console](https://ci.chromium.org/p/flutter/g/engine/console).
|
||||
|
||||
|
||||
### Making a breaking change
|
||||
|
||||
Our [breaking change policy](../contributing/Tree-hygiene.md#handling-breaking-changes) disallows making changes to the engine that require changes to the framework. If you find the need to do this, you should instead make a soft-breaking change which you can land in multiple phases, as described in that process.
|
||||
|
||||
### Doing a manual roll
|
||||
|
||||
To roll the engine manually in the case you have a breaking change exemption, you'll need to land the change to `engine.version` manually in the same PR to the framework as the one where you fix the framework to work with the new API.
|
||||
|
||||
When you change the `engine.version` file locally, you should delete `$FLUTTER_ROOT/bin/cache` and then run `flutter precache` to ensure that all your local artifacts and snapshots are updated. You can then run tests and be sure that they are running against the latest version of the assets you need.
|
||||
|
||||
You may find it helpful to use the [`$ENGINE_ROOT/src/flutter/tools/engine_roll_pr_desc.sh`](https://github.com/flutter/engine/blob/main/tools/engine_roll_pr_desc.sh) to create a PR description. Doing this helps us track down what commits have rolled in more quickly, and properly link to other commits and pull requests for commenting and tracking.
|
||||
|
||||
For example, to generate a description from hash deadbeef to beefdead:
|
||||
|
||||
```bash
|
||||
$ ./tools/engine_roll_pr_desc.sh deadbeef..beefdead
|
||||
```
|
||||
|
||||
_See also: [Debugging the engine](../engine/Debugging-the-engine.md), which includes instructions on bisecting a roll failure._
|
||||
|
||||
|
||||
## Dart to Engine
|
||||
|
||||
The Dart SDK is automatically rolled into the engine on a regular basis, following the steps laid out at the [Rolling Dart](Rolling-Dart.md) page. Since this process is a bit more involved, this autoroller does not use the Skia infrastructure and has a custom dashboard hosted at [go/dart-sdk-roller-dashboard](http://go/dart-sdk-roller-dashboard) (**note: this is likely only accessible from a machine on the Google network**). Using the dashboard, the autoroller can be paused, rolls can be triggered and cancelled, and rolls to a particular revision can be done.
|
||||
The Dart SDK is automatically rolled by <https://autoroll.skia.org/r/dart-sdk-flutter>.
|
||||
|
||||
If there are any issues with this process or the autoroller dashboard, contact bkonyi@ or a member of the Dart VM team.
|
||||
|
||||
## Flutter Pub Roller
|
||||
|
||||
The bot account [flutter-pub-roller-bot](https://github.com/flutter-pub-roller-bot) runs the script at
|
||||
https://github.com/flutter/flutter/blob/main/dev/conductor/bin/packages_autoroller on post-submit of
|
||||
[`packages_autoroller`](../../dev/conductor/bin/packages_autoroller) on post-submit of
|
||||
every framework commit to keep the pub dependencies in the [framework](https://github.com/flutter/flutter)
|
||||
up to date.
|
||||
up to date.
|
||||
|
||||
@ -1,18 +1,15 @@
|
||||
# Rolling the Dart SDK
|
||||
|
||||
Flutter is a series of connected repositories. Within each repository there are files (normally named `DEPS`) which determine which version of the other repositories the repository currently works with.
|
||||
|
||||
The three relevant repositories for this document are:
|
||||
|
||||
- Flutter. This is the top half of the Flutter project: [flutter/flutter on GitHub](https://github.com/flutter/flutter)
|
||||
- Engine. This is the Flutter Engine, the lower half of the Flutter project: [flutter/engine on GitHub](https://github.com/flutter/engine)
|
||||
- Flutter. The Flutter project: [flutter/flutter on GitHub](https://github.com/flutter/flutter)
|
||||
- Dart SDK. This is the language used for big parts of Flutter: [dart-lang/sdk on GitHub](https://github.com/dart-lang/sdk)
|
||||
|
||||
This document describes how to update the version of the Dart SDK that the Engine uses, and then update the version of the Engine that Flutter uses, so that Flutter gets the latest Dart.
|
||||
|
||||
The Flutter repo does not use a `DEPS` file and `gclient` for its dependencies. Instead, the Flutter Engine version is in `flutter/bin/internal/engine.version`.
|
||||
|
||||
## Dart Autoroller
|
||||
|
||||
Dart is now automatically rolled into the Flutter engine repository on a regular basis. See [Autorollers](Autorollers.md) for more information.
|
||||
Dart is now automatically rolled into the Flutter repository on a regular basis. See [Autorollers](Autorollers.md) for more information.
|
||||
|
||||
## Using dart_roll_helper.py to roll the version of Dart used by the engine
|
||||
|
||||
@ -54,8 +51,8 @@ If the script completes without errors, move on to step 10 in the next section t
|
||||
linked to from [our contributing guide](../../CONTRIBUTING.md).
|
||||
2. Build the engine according to the instructions on the [Compiling the engine](../engine/contributing/Compiling-the-engine.md) page.
|
||||
3. Select a target Dart revision, typically use the [latest revision](https://github.com/dart-lang/sdk/commits/main). Check that the tests for that revision have all passed (all green) on the [Dart buildbot](https://ci.chromium.org/p/flutter/g/engine/console) and the [Internal Dart Flutter buildbot](https://ci.chromium.org/p/dart/g/flutter/console).
|
||||
4. Create a PR (see [Tree hygiene](../contributing/Tree-hygiene.md)) that updates `dart_revision` in [DEPS](https://github.com/flutter/engine/blob/main/DEPS) to your selected revision. Invoke `gclient sync` in the src directory to ensure versions corresponding to the DEPS file are synced up.
|
||||
5. Update all Dart-dependent DEPS entries using `engine/src/tools/dart/create_updated_flutter_deps.py` script. In case script complains that dart dependency was removed, remove entry from flutter DEPS file manually. If the list of library source files or patch files is modified, update the file [libraries.yaml](https://github.com/flutter/engine/blob/main/lib/snapshot/libraries.yaml) and regenerate the corresponding json file.
|
||||
4. Create a PR (see [Tree hygiene](../contributing/Tree-hygiene.md)) that updates `dart_revision` in [DEPS](../../DEPS) to your selected revision. Invoke `gclient sync` in the src directory to ensure versions corresponding to the DEPS file are synced up.
|
||||
5. Update all Dart-dependent DEPS entries using [`create_updated_flutter_deps.py`](../../engine/src/tools/dart/create_updated_flutter_deps.py) script. In case script complains that dart dependency was removed, remove entry from flutter DEPS file manually. If the list of library source files or patch files is modified, update the file [`libraries.yaml`](../../engine/src/flutter/lib/snapshot/libraries.yaml) and regenerate the corresponding json file.
|
||||
6. Invoke `gclient sync` in the src directory to ensure versions corresponding to the DEPS file are synced up.
|
||||
7. Build the debug, profile, and release versions of the engine, following the normal [Compiling the engine](../engine/contributing/Compiling-the-engine.md) instructions. You will need to build the host versions of the engine too. Here is a script with the build commands:
|
||||
|
||||
|
||||
@ -167,7 +167,7 @@ and `local-engine`, which specifies which build of the engine to use.
|
||||
|
||||
**Important:** before building your local engine, you should ensure that your engine feature branch is based on the
|
||||
same upstream version of the engine that the Flutter SDK/flutter tool has pinned. You can find the engine version
|
||||
that the Flutter SDK has pinned at `flutter/bin/internal/engine.version`.
|
||||
that the Flutter SDK has pinned at `bin/cache/engine.stamp`.
|
||||
|
||||
A typical invocation would be: `--local-engine-src-path /path/to/engine/src --local-engine=android_debug_unopt --local-engine-host=host_debug_unopt`.
|
||||
|
||||
@ -177,13 +177,6 @@ You can also set the environment variable `$FLUTTER_ENGINE` instead of specifyin
|
||||
|
||||
The `--local-engine` should specify the build of the engine to use, e.g. a profile build for Android, a debug build for Android, or whatever. It must match the other arguments provided to the tool, e.g. don't use the `android_debug_unopt` build when you specify `--release`, since the Debug build expects to compile and run Dart code in a JIT environment, while `--release` implies a Release build which uses AOT compilation.
|
||||
|
||||
<!-- TODO(matanl): https://github.com/flutter/flutter/issues/132245, update this. -->
|
||||
|
||||
> ⚠️ **WARNING**: As of [#132245](https://github.com/flutter/flutter/issues/132245), `--local-engine-host` will be mandatory.
|
||||
>
|
||||
> If you're currently relying on the host engine being implicitly defined, you will need to update your workflow to explicitly specify the host engine.
|
||||
> For example, if you're currently running `flutter run --local-engine=android_debug_unopt`, you will need to run `flutter run --local-engine=android_debug_unopt --local-engine-host=host_debug_unopt` instead.
|
||||
|
||||
If you've modified the public API of `dart:ui` in your local build of the engine
|
||||
and you need to be able to analyze the framework code with the new API,
|
||||
you will need to add a `dependency_overrides` section pointing to your
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
## Symbolicating stack traces for engine crashes
|
||||
# Symbolicating stack traces for engine crashes
|
||||
|
||||
iOS app archives produced using Flutter 3.24 or later embed engine debugging symbols and thus crashes are symbolicated by default.
|
||||
|
||||
The easiest way to symbolicate stack traces for Android and older iOS apps is to run the [dart_ci symbolizer locally](https://github.com/dart-lang/dart_ci/blob/main/github-label-notifier/symbolizer/README.md#using-this-locally). If that is not an option, the steps below explain how to do it manually.
|
||||
|
||||
### Android
|
||||
## Android
|
||||
|
||||
#### Get the symbols
|
||||
### Get the symbols
|
||||
|
||||
1. Get the Flutter Framework or Flutter Engine revision from the report. If you have the Engine revision, skip to step 3.
|
||||
|
||||
2. Get the Engine revision from the Framework (this could be automated). https://github.com/flutter/flutter/blob/main/bin/internal/engine.version is the file which contains the information. Substitute the framework hash for `main` in that url.
|
||||
2. Get the Engine revision from the Framework (this could be automated). `flutter/blob/main/bin/cache/engine.stamp` is the file which contains the information. Substitute the framework hash for `main` in that url.
|
||||
|
||||
3. With the full engine revision (e.g. cea5ed2b9be42a981eac762af3664e4a17d0a53f), you can now get the proper symbol files:
|
||||
|
||||
@ -20,12 +20,12 @@ The easiest way to symbolicate stack traces for Android and older iOS apps is to
|
||||
|
||||
Please be aware that the type of the symbol must match your Apps release type. In above example, this refers to a android-arm **debug** build. If you work with a **release** or **profile** build, the URLs would look like this:
|
||||
|
||||
* https://storage.cloud.google.com/flutter_infra_release/flutter/cea5ed2b9be42a981eac762af3664e4a17d0a53f/android-arm-release/symbols.zip
|
||||
* https://storage.cloud.google.com/flutter_infra_release/flutter/cea5ed2b9be42a981eac762af3664e4a17d0a53f/android-arm-profile/symbols.zip
|
||||
* <https://storage.cloud.google.com/flutter_infra_release/flutter/cea5ed2b9be42a981eac762af3664e4a17d0a53f/android-arm-release/symbols.zip>
|
||||
* <https://storage.cloud.google.com/flutter_infra_release/flutter/cea5ed2b9be42a981eac762af3664e4a17d0a53f/android-arm-profile/symbols.zip>
|
||||
|
||||
You have to use your browser because it does authentication.
|
||||
|
||||
#### Symbolicate with ndk-stack
|
||||
### Symbolicate with ndk-stack
|
||||
|
||||
Once you have the symbols unzipped, you can use ndk-stack from your Android NDK. Suppose `stack.txt` contains the stack (including the leading `*** *** ***` line from the crash):
|
||||
|
||||
@ -40,7 +40,7 @@ Or on macOS:
|
||||
|
||||
Some debugging tools, like _pidcat_ may not show the full tombstone logs. In that case, please use `adb logcat` directly and copy the full output.
|
||||
|
||||
#### Symbolicate with addr2line
|
||||
### Symbolicate with addr2line
|
||||
|
||||
A alternative way to symbolicate is by using the addr2line tool. It is bundled with the NDK.
|
||||
To use it, simply call it with a path to the .so file downloaded above and feed the stack addresses to it manually. For example, on macOS:
|
||||
@ -55,7 +55,7 @@ _The tool is now awaiting your input, so let's feed it a memory address_:
|
||||
```
|
||||
This revealed address `0x00000000006a26ec` to correspond with `dart_api_impl.cc:1366`.
|
||||
|
||||
#### Making sure you got the right libflutter.so
|
||||
### Making sure you got the right libflutter.so
|
||||
|
||||
The build system sets a build id for each `libflutter.so` file. In the tombstones, you would see the ID like so:
|
||||
|
||||
@ -65,24 +65,23 @@ The build system sets a build id for each `libflutter.so` file. In the tombstone
|
||||
|
||||
This equals to a build id of **34ad5bdf0830d77a**. The `libflutter.so` debug files downloaded as shown above could be verified using the `file` command:
|
||||
|
||||
```
|
||||
```sh
|
||||
% file ~/Downloads/libflutter.so
|
||||
/Users/user/Downloads/libflutter.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[xxHash]=34ad5bdf0830d77a, with debug_info, not stripped
|
||||
```
|
||||
|
||||
Ensure the build IDs match, else you will not be able to symbolicate.
|
||||
|
||||
#### Expanding Git Revisions
|
||||
### Expanding Git Revisions
|
||||
|
||||
Go to a commit page with the short commit as the last fragment of the URL:
|
||||
(e.g. https://github.com/flutter/flutter/commit/9cb914df1 or https://github.com/flutter/engine/commit/2a13567) and then find the full revision on the page.
|
||||
|
||||
|
||||
#### Symbolicating local builds
|
||||
### Symbolicating local builds (Android)
|
||||
|
||||
If you have made your own builds, you can use ndk-stack directly:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
# dev/engine is where your engine's .gclient file is
|
||||
# android_debug_unopt is whatever build of your engine you are using
|
||||
adb logcat | ~/dev/engine/src/third_party/android_tools/ndk/prebuilt/linux-x86_64/bin/ndk-stack -sym ~/dev/engine/src/out/android_debug_unopt
|
||||
@ -94,8 +93,8 @@ Since Flutter 3.24, symbols can be found in the Flutter framework's artifact
|
||||
cache, within the xcframework bundle at
|
||||
`bin/cache/artifacts/engine/ios-release/Flutter.xcframework`.
|
||||
|
||||
* Symbols for device builds are in the `ios-arm64/dSYMs/Flutter.framework.dSYM` bundle.
|
||||
* Symbols for simulator builds are in the `ios-arm64_x86_64-simulator/dSYMs/Flutter.framework.dSYM` bundle.
|
||||
* Symbols for device builds are in the `ios-arm64/dSYMs/Flutter.framework.dSYM` bundle.
|
||||
* Symbols for simulator builds are in the `ios-arm64_x86_64-simulator/dSYMs/Flutter.framework.dSYM` bundle.
|
||||
|
||||
For versions prior to Flutter 3.24, the dSYM bundle can downloaded from Google
|
||||
Cloud Storage. Follow the steps from the Android section in this guide, but in
|
||||
@ -116,7 +115,7 @@ Since Flutter 3.27, symbols can be found in the Flutter framework's artifact
|
||||
cache, within the xcframework bundle at
|
||||
`bin/cache/artifacts/engine/darwin-x64-release/Flutter.xcframework`.
|
||||
|
||||
* Symbols for device builds are in the `macos-arm64_x86_64/dSYMs/FlutterMacOS.framework.dSYM` bundle.
|
||||
* Symbols for device builds are in the `macos-arm64_x86_64/dSYMs/FlutterMacOS.framework.dSYM` bundle.
|
||||
|
||||
For versions prior to Flutter 3.27, the dSYM bundle can downloaded from Google
|
||||
Cloud Storage. Follow the steps from the Android section in this guide, but in
|
||||
@ -131,11 +130,11 @@ schema:
|
||||
`https://storage.googleapis.com/flutter_infra_release/flutter/cf4507ae1008c11c6155d31e852999d75670afcf/darwin-x64-release/framework.zip`
|
||||
(replace the engine hash with your hash).
|
||||
|
||||
#### Symbolicating local builds
|
||||
### Symbolicating local builds (macOS)
|
||||
|
||||
If you built your local engine in debug or profile Dart modes, the framework's dylib's symbols aren't stripped and are available by default.
|
||||
|
||||
#### Crashes in Dart AOT code
|
||||
### Crashes in Dart AOT code
|
||||
|
||||
If the crash is in AOT Dart code (in `--release` or `--profile` builds) on iOS, and you can build your own engine, these steps will be helpful for the VM team to fix the bug:
|
||||
|
||||
@ -158,8 +157,7 @@ If the crash is in AOT Dart code (in `--release` or `--profile` builds) on iOS,
|
||||
* Look for the function name (by substring match) in this file and copy out that information to the bug.
|
||||
* Ping someone on dart-lang/sdk.
|
||||
|
||||
|
||||
### Android Local Engine Builds
|
||||
## Android Local Engine Builds
|
||||
|
||||
When running with a local engine build, the symbolization workflow can be cumbersome and unecessary. Instead, it is possible to build the engine itself with symbols and disable Gradle's automatic symbol stripping. This is also required to see symbol names in Android Studio CPU profiles.
|
||||
|
||||
@ -167,9 +165,8 @@ When running with a local engine build, the symbolization workflow can be cumber
|
||||
|
||||
2. In the flutter project file `android/app/build.gradle`, add the following line under the `android` block:
|
||||
|
||||
```
|
||||
packagingOptions{
|
||||
doNotStrip "**/*.so"
|
||||
}
|
||||
|
||||
```gradle
|
||||
packagingOptions{
|
||||
doNotStrip "**/*.so"
|
||||
}
|
||||
```
|
||||
|
||||
@ -24,7 +24,6 @@ This is an index of team-facing documentation for the [flutter/engine repository
|
||||
- [Supporting legacy platforms](Supporting-legacy-platforms.md)
|
||||
- [Testing Android Changes in the Devicelab on an Emulator](https://github.com/flutter/flutter/blob/master/docs/platforms/android/Testing-Android-Changes-in-the-Devicelab-on-an-Emulator.md)
|
||||
- [Testing the engine](./testing/Testing-the-engine.md)
|
||||
- [Testing presubmit Engine PRs with the Flutter framework](Testing-presubmit-Engine-PRs-with-the-Flutter-framework.md)
|
||||
- [The Engine architecture](https://github.com/flutter/flutter/blob/master/docs/about/The-Engine-architecture.md)
|
||||
- [Upgrading Engine's Android API version](https://github.com/flutter/flutter/blob/master/docs/platforms/android/Upgrading-Engine's-Android-API-version.md)
|
||||
- [Using the Dart Development Service (DDS) and Flutter DevTools with a custom Flutter Engine Embedding](./Using-the-Dart-Development-Service-(DDS)-and-Flutter-DevTools-with-a-custom-Flutter-Engine-Embedding.md)
|
||||
|
||||
@ -1,69 +0,0 @@
|
||||
# Running Framework presubmit tests on Engine PRs
|
||||
|
||||
This documentation describes how to run flutter/flutter presubmit checks on flutter/engine PRs before submitting them.
|
||||
|
||||
## Overview
|
||||
|
||||
1. Create your engine pull request with the `test: all` label.
|
||||
2. Wait for all presubmit checks on your flutter/engine PR to be green.
|
||||
3. Determine the commit hash for your flutter/engine PR.
|
||||
4. Create and upload a flutter/flutter PR, (OR run tests locally).
|
||||
5. Wait for flutter/flutter presubmits/tests to run ☕.
|
||||
|
||||
## 1. Create your engine pull request with the `test: all` label.
|
||||
|
||||
When creating your PR, add the `test: all` label *before* submitting the PR to
|
||||
CI. This will ensure that all builds required for framework testing are
|
||||
triggered.
|
||||
|
||||
If you sent out your PR without adding the `test: all` label, you can add it,
|
||||
then re-push your branch to re-trigger presubmits.
|
||||
|
||||
By default, [not all builds and tests are run][engine_presubmits] in engine
|
||||
presubmits. When our CI is able to determine that certain shards are unaffected
|
||||
by a change, via a `runIf` clause in our `.ci.yaml`, for example, it will be
|
||||
skipped. Many framework tests, however, assume all build products are present
|
||||
and will trigger a `flutter precache`, which will fail with a 404 on missing
|
||||
build artifacts.
|
||||
|
||||
[engine_presubmits]: ci/Engine-pre-submits-and-post-submits.md#running-post-submits-eagerly
|
||||
|
||||
## 2. Wait
|
||||
|
||||
Contemplate the nature of the universe or why it is that this workflow was necessary for your situation. Could tests have been added to the engine? If not, get youself some coffee and a cookie. You'll need them.
|
||||
|
||||
## 3. The commit hash
|
||||
|
||||
1. Go to the "Commits" tab in the GitHub UI for you Engine PR.
|
||||
1. Click the button to copy the most recent commit hash to your clipboard.
|
||||
|
||||
<img width="1128" alt="Screenshot 2023-08-04 at 12 54 55 PM" src="https://github.com/flutter/flutter/assets/6343103/491be0dd-e29b-4057-a077-3a28d3beec9e">
|
||||
|
||||
## 4. Create and upload a flutter/flutter PR.
|
||||
|
||||
Edit your flutter/flutter checkout as follows:
|
||||
|
||||
1. `bin/internal/engine.version` should be edited to contain the commit hash from (2).
|
||||
1. `bin/internal/engine.realm` should be edited to contain the string `flutter_archives_v2`.
|
||||
|
||||
To run flutter/flutter presubmits on CI, you can accomplish these two edits directly in the GitHub editor UI, if desired. Otherwise, upload a flutter/flutter PR with these changes.
|
||||
|
||||
You can also build apps, and run tests locally at this point.
|
||||
|
||||
## 5. Wait for flutter/flutter presubmits to run ☕.
|
||||
|
||||
The flutter/flutter presubmit checks will run. There will be at least two failures:
|
||||
1. A Flutter CLI test will ensure that a PR with a non-empty `engine.realm` file will fail a presubmit check.
|
||||
1. The `fuchsia_precache` test will fail because Fuchsia artifacts are not uploaded from Engine presubmit runs.
|
||||
|
||||
Any other failures are possibly due to the changes to flutter/engine, so deflake and examine them carefully.
|
||||
|
||||
## 6. Devicelab tests
|
||||
|
||||
A subset of devicelab tests are available for optionally running in presubmit on flutter/flutter PRs. They are the tests listed in the flutter/flutter [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) file that are prefixed with `Linux_android`, `Mac_android`, and `Mac_ios`.
|
||||
|
||||
To run one of these tests, remove the line `presubmit: false` from the `.ci.yaml` file under the test you'd like to run. For an example, see the PR [here](https://github.com/flutter/flutter/pull/135254).
|
||||
|
||||
<img width="1117" alt="Screenshot 2023-09-21 at 3 19 51 PM" src="https://github.com/flutter/flutter/assets/6343103/9d234e82-1d6e-430b-a08e-d70bb9267462">
|
||||
|
||||
This will trigger the devicelab test to run. The test will show up in the list of presubmit checks, and you can click through to the [LUCI page](https://ci.chromium.org/ui/p/flutter/builders/try/Linux_android%20new_gallery__transition_perf/2/overview) to see the results.
|
||||
Loading…
x
Reference in New Issue
Block a user