test(flutter): exercise iOS boot-cap defaults on the Flutter-iOS leg (#428) - #606
Open
goosewobbler wants to merge 1 commit into
Open
test(flutter): exercise iOS boot-cap defaults on the Flutter-iOS leg (#428)#606goosewobbler wants to merge 1 commit into
goosewobbler wants to merge 1 commit into
Conversation
…428) Drop the explicit appium:wdaLaunchTimeout and appium:simulatorStartupTimeout from the Flutter iOS e2e capability so native-mobile-core's applyBootCapDefaults (720000 / 240000, apply-if-unset) is verified end-to-end, not just in unit tests. Trialling on Flutter-iOS first (per #428) — the default wdaLaunchTimeout is a flat 720000, more generous than the prior FLUTTER_WDA_DD-conditional 120000 ceiling. Kept: the explicit appium:udid pin (avoids the #359 wrong-sim flake), the WDA startup-retry bumps, and the prebuilt-WDA reuse (usePreinstalledWDA + prebuiltWDAPath) — none of which applyBootCapDefaults covers. Refs #428
Contributor
|
| Filename | Overview |
|---|---|
| e2e/wdio.flutter.conf.ts | The Flutter iOS capability now relies on shared boot-cap defaults; no reachable regression was identified in the current CI configuration. |
Reviews (1): Last reviewed commit: "test(flutter): exercise iOS boot-cap def..." | Re-trigger Greptile
Contributor
Release Preview — no release
Updated automatically by ReleaseKit |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Drops the explicit
appium:wdaLaunchTimeout+appium:simulatorStartupTimeoutfrom the Flutter iOS e2e capability sonative-mobile-core'sapplyBootCapDefaults(720000 / 240000, apply-if-unset, invoked byMobileBaseLauncher) is exercised end-to-end — today those defaults only have unit coverage because every e2e config pins the values by hand.Per #428, this trials one platform first (Flutter-iOS) rather than doing RN-iOS + Flutter-iOS together, because the flat default
wdaLaunchTimeout: 720000is more generous than the priorFLUTTER_WDA_DD ? 120000 : 720000ceiling and could mask a slow first session — worth a single-leg CI signal before extending.Kept (as the issue calls out)
appium:udid— the exact pre-booted sim pin (dropping it reintroduces the react-native iOS E2E: flaky first-session (api) cold-start — FrontBoard / sim-boot / socket #359 "booted a different sim" flake).appium:wdaStartupRetries/wdaStartupRetryIntervaland the prebuilt-WDA reuse (usePreinstalledWDA+prebuiltWDAPath) —applyBootCapDefaultsonly sets timeouts/headless, so these must stay explicit.Verification
format:check+@wdio/flutter-servicetypecheck pass. The real signal is this PR's Flutter [iOS] e2e leg going green with the defaults applied.Refs #428
🤖 Generated with Claude Code