fix(onboarding): make reset/restore-onboarding.sh build-kind aware (ENG-340) - #520
Open
pnewsam wants to merge 2 commits into
Open
fix(onboarding): make reset/restore-onboarding.sh build-kind aware (ENG-340)#520pnewsam wants to merge 2 commits into
pnewsam wants to merge 2 commits into
Conversation
…NG-340) Since ENG-324 each build kind keeps its state in a separate home (~/.cowork-dev / -preview / -stable, ~/.cowork for prod) so builds never share a SQLite DB. The onboarding reset/restore scripts still only touched ~/.anton and the prod ~/.cowork, so resetting a dev/preview/stable build did nothing to the home it actually uses. - Take the build kind as an argument (default dev) and reset the matching per-kind home (~/.cowork-<kind>, ~/.cowork for prod). - For prod only, move the legacy ~/.anton migration sources aside so first-run migrateLegacyHome can't re-seed credentials and defeat the reset; non-prod homes never inherit that prod-era state. - restore-onboarding.sh reverses the same per-kind backups. Dev tooling only: these scripts are run by hand for local onboarding QA and touch nothing in the app, CI, or production. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… (ENG-340) Follow-on to the per-channel app-identity work (#387): since each non-prod build kind gets its own Electron app name (app.setName → a separate userData dir), the reset/restore scripts must target the channel-specific dir, not the shared ~/Library/Application Support/anton. - Derive ELECTRON_DIR from a per-kind app-name map (prod stays 'anton'; non-prod kinds mirror channels.ts appName — the `stable` kind targets the staging env so its app is labelled "Staging"). - Reword the localStorage/consent comments: state now lives under the channel's OWN userData dir, so a reset clears only the kind you pass. Kept here (rather than in #387) so #520 owns all onboarding-script changes and stays independently mergeable on staging; the app-name map is a hardcoded mirror either way (bash can't import channels.ts). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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 & why
Since ENG-324, each build kind keeps its state in a separate config home so builds never share a SQLite DB (an older build reopening a DB a newer build advanced fails to start on an unrecognized Alembic migration):
dev→~/.cowork-devpreview→~/.cowork-previewstable→~/.cowork-stableprod→~/.coworkThe onboarding
reset/restorescripts never got the memo — they only touched~/.antonand the prod~/.cowork. So runningreset-onboarding.shagainst adev/preview/stablebuild did nothing to the home that build actually uses, and you couldn't get a clean first-run state to test onboarding.Changes
reset-onboarding.sh/restore-onboarding.shtake the build kind as an argument (defaultdev) and reset/restore the matching per-kind home.~/.antonmigration sources aside so first-runmigrateLegacyHomecan't re-seed credentials and defeat the reset. Non-prod homes never inherit that prod-era state, so they're left untouched.Also: per-channel Electron userData dir
Companion to the per-channel app-identity work in #387. Once each non-prod build kind gets its own Electron app name (
app.setName→ a separate~/Library/Application Support/<name>dir), a reset must clear that dir, not the sharedantonone. So the scripts now deriveELECTRON_DIRfrom a per-kind app-name map (prod staysanton; thestablekind targets the staging env, so its app is labelled "Staging"). Kept here — rather than in #387 — so this PR owns all onboarding-script changes and stays independently mergeable onstaging. The map is forward-compatible: before #387 ships every kind is stillanton, so the per-kind dirs simply don't exist yet and the reset skips them.Risk
None to production. These are hand-run local dev-QA scripts — they touch no application code, no CI, and nothing that ships. Split out of #385 (the build-channel consolidation) because it's a separate concern (ENG-340) with no review risk.
Test plan
Run
./scripts/reset-onboarding.sh devthen./scripts/restore-onboarding.sh devand confirm~/.cowork-devis backed up and restored.🤖 Generated with Claude Code