Give Safari its own build dir and automate the TestFlight release - #1529
Merged
Conversation
The Safari webpack build shared `build/firefox`: `buildDir` only branched chrome vs everything-else, so a Safari run overwrote the Firefox output with the Safari manifest, and `cleanUpBuildDir` wiped `build/safari/Casper Wallet`, a path nothing ever wrote to. The Xcode project read its resources from `build/firefox` for the same reason. Safari now builds into `build/safari` and the Xcode project reads from there. `build:all` covers it, so one run produces every deliverable. The `.app` was only ever ad-hoc signed — no DEVELOPMENT_TEAM in the project, and `xcodebuild -alltargets` produces no archive — so it could not go to TestFlight anyway. It is built and submitted from Xcode instead, and `build:safari` now mirrors `build:chrome`/`build:firefox`: resources only.
The archive name carried a hardcoded `2.7.0rc1`, so every run of `build:all` since the 2.7.0 bump has produced a file claiming to be the first release candidate of a version it may no longer be building. The version now comes from package.json and the rc number from the archives already in build/: a version change starts over at rc1, a rebuild of the same version takes the highest rc there and adds one. Clearing build/ restarts the count, which is why the zip names the build dirs it wants instead of `./*` — that glob would have nested every past archive into the new one, and it is also how Safari stays out: Xcode reads those resources from build/safari and ships them inside the app, so the store archive has no use for them.
Uploading a build meant opening build/chrome in Finder, selecting its contents
and zipping them by hand — the stores want the extension at the zip root, so
zipping the folder itself does not work.
build:all now writes casper-wallet-{chrome,firefox}-<version>rc<n>#<sha>.zip
next to the bundle, each zipped from inside its build dir. Dotfiles are left
out: the manual route picked up whatever .DS_Store the Finder visit had just
created. The rc counter only ever globs the bundle name, so these do not
advance it.
The web-ext `package:chrome` path stays as it is — the release workflow uploads
its artifact to the Chrome Web Store.
`start:safari` ran `./convert-web-extension.sh`, a file that has never existed in this repository — the command has been dead since it was written. It was built around generating a throwaway Xcode project into the Safari build dir (`ExtensionBuildPath.Safari` used to end in the extension name for exactly that reason) and rebuilding it from a webpack plugin on every recompile. The repo has carried a committed `xcode-project/` for a long time instead. Removing it takes `xcode-build-webpack-plugin` with it — unpublished since 2022, and required at the top of webserver.js, so `start:chrome` and `start:firefox` were loading it too. Safari development is `npm run build:safari` plus Run in Xcode; there is no watch mode.
`npm run release:safari` builds the web-extension resources, stamps the version into the Xcode project, archives the app and uploads it to App Store Connect. MARKETING_VERSION follows package.json, so bumping the app version is a package.json edit and nothing else; CURRENT_PROJECT_VERSION increments on every upload and is restored again when a run ships nothing, so only a real upload consumes a build number. Credentials come from a gitignored .env.release rather than .env, which build_src.sh copies into the source-review package handed to store reviewers — the script refuses to start if it finds them there. That package now excludes .p8 files as well, so the API key may sit in the repo root without riding along.
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.
The Safari build shared
build/firefox, and the release steps around it were partly manual and partly dead. This branch separates the Safari output, makes the release archives self-describing, and adds the TestFlight step that was missing entirely.Safari gets its own build dir.
buildDironly branched chrome vs everything-else, so a Safari run overwrote the Firefox output with the Safari manifest. The.appstep goes with it — the committedxcode-project/is what builds the app.Archive names come from
package.json. The name carried a hardcoded2.7.0rc1, so everybuild:allsince the version bump produced a file claiming to be the first release candidate of a version it may no longer have been building. The version now comes frompackage.json, and the rc number from the archives already sitting inbuild/.Store-ready archives for Chrome and Firefox. Uploading used to mean opening the build dir in Finder, selecting its contents and zipping them by hand — the stores want the extension at the zip root, so zipping the folder does not work.
build:allnow writes those archives directly, without the.DS_Storethe Finder visit left behind.The dead Safari dev-server flow is removed.
start:safariinvoked./convert-web-extension.sh, a file that has never existed in this repository. Removing it dropsxcode-build-webpack-plugin— unpublished since 2022, and required at the top ofwebserver.js, sostart:chromeandstart:firefoxwere loading it too. Safari development isnpm run build:safariplus Run in Xcode; there is no watch mode.npm run release:safarifinishes the job. It builds the web-extension resources, stamps the version into the Xcode project, archives the app and uploads it to App Store Connect.MARKETING_VERSIONfollowspackage.json, so bumping the app version is apackage.jsonedit and nothing else.CURRENT_PROJECT_VERSIONincrements on every upload and is restored again when a run ships nothing, so only a real upload consumes a build number.--no-uploadstops at a signed.pkg, which is the way to set up signing on a new machine.Credentials come from a gitignored
.env.releaserather than.env, whichbuild_src.shcopies into the source-review package handed to store reviewers — the script refuses to start if it finds them there. That package now excludes.p8files as well, so the API key may sit in the repo root without riding along.2.7.0 (160) was archived and uploaded to TestFlight through this path.