Sign a Simulator into WordPress.com from a launch-argument token#25801
Draft
jkmassel wants to merge 5 commits into
Draft
Sign a Simulator into WordPress.com from a launch-argument token#25801jkmassel wants to merge 5 commits into
jkmassel wants to merge 5 commits into
Conversation
Add `Scripts/sim-signin.sh`, a one-command wrapper around `xcrun simctl launch` that signs a Simulator into WordPress.com with a bearer token, and make the existing `-ui-test-wpcom-token` launch argument finish sign-in automatically instead of requiring a tap on "Continue with WordPress.com". `autoSignInUITestWPComAccountIfNeeded()` mirrors the existing `autoSignInUITestSite()` hook: it runs from `showSignInUI()`, no-ops unless the token argument is present and no account is signed in, then runs the real sign-in flow and swaps the window root with `windowManager.showUI()`.
Collaborator
Generated by 🚫 Danger |
Add a named `-t, --wpcom-token <token>` option alongside the positional form, and reject a missing option value instead of shifting past the end.
Introduce `WordPressDotComAuthenticator.launchArgumentToken`, which reads the new `-wpcom-token` launch argument and falls back to the legacy `-ui-test-wpcom-token`. Route both read sites — `attemptSignIn` and `autoSignInUITestWPComAccountIfNeeded()` — through it, and switch the helper script to pass `-wpcom-token`.
Contributor
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 33217 | |
| Version | PR #25801 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 5b8b264 | |
| Installation URL | 29gpic3p7ivc0 |
Contributor
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 33215 | |
| Version | PR #25801 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | b022cf6 | |
| Installation URL | 15dhsndifd1e0 |
Contributor
🤖 Build Failure AnalysisThis build has failures. Claude has analyzed them - check the build annotations for details. |
The launch argument is `-wpcom-token`, not UI-test-scoped, so `autoSignInUITestWPComAccountIfNeeded()` was misleading. Rename it to `autoSignInWPComAccountFromLaunchArgumentIfNeeded()`.
So the token can be set once instead of pasted every launch, sim-signin.sh falls back to the WPCOM_TOKEN environment variable, then a ~/.wpcom-token file, when neither --wpcom-token nor a positional token is given. Precedence: flag > env var > file.
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
3 participants
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.
Summary
Scripts/sim-signin.sh, a one-command wrapper aroundxcrun simctl launchthat signs an iOS Simulator into WordPress.com with a bearer token.-wpcom-tokenlaunch argument (the legacy-ui-test-wpcom-tokenstill works as a backward-compatibility shim).Background
trunkalready reads a-ui-test-wpcom-tokenlaunch argument insideWordPressDotComAuthenticator.attemptSignIn— but only when the user taps "Continue with WordPress.com" on the login screen. Signing a Simulator in therefore still needed a manual tap. This is the launch-argument approach chosen over device-to-device session transfer.Changes
1.
Scripts/sim-signin.shTakes the token via
-t, --wpcom-token(or positionally), maps--appto the bundle id (com.automattic.jetpack/org.wordpress), defaults to the booted simulator, and — with--reset— runs a separate-ui-test-reset-everythinglaunch first (the reset must not be combined with the credential arguments).2.
-wpcom-tokenlaunch argumentWordPressDotComAuthenticator.launchArgumentTokenresolves the token from the new-wpcom-tokenargument, falling back to the legacy-ui-test-wpcom-token. Both the automatic sign-in and the existingattemptSignInpath read through it, so nothing still passing the old argument breaks.3. Automatic sign-in
WordPressAppDelegate.autoSignInUITestWPComAccountIfNeeded()mirrors the existingautoSignInUITestSite()hook and is called fromRootViewCoordinator.showSignInUI(). It no-ops unless the token argument is present and no account is signed in, then runs the realsignIn(context: .default)flow and swaps the window root withwindowManager.showUI().Posting
WPSigninDidFinishNotificationalone creates the account but leaves the app on the login screen — the explicitwindowManager.showUI()is what lands it on the app.Test plan
Scripts/sim-signin.sh --wpcom-token <valid-token>→ app signs in and lands on the site with no taps.-ui-test-wpcom-token <token>still signs in.--resetagainst a signed-in app → state is wiped, then re-signed-in.--app wordpresstargetsorg.wordpress.Related