Publish standalone CLI bundles to Apps CDN and install from the CDN latest alias - #3835
Conversation
📊 Performance Test ResultsComparing 0f0e844 vs trunk app-size
site-editor
site-startup
Results are median values from multiple test runs. Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff) |
fredrikekelund
left a comment
fredrikekelund
left a comment
There was a problem hiding this comment.
I'm not knowledgeable about Fastlane to the point about providing detailed feedback about the Fastfile implementation, but this LGTM 👍
| bundle exec fastlane notarize_binary | ||
|
|
||
| echo "--- :package: Building standalone CLI bundle" | ||
| npm run cli:bundle -- darwin {{matrix}} |
There was a problem hiding this comment.
This probably won't optimize anything beyond the micro level, and we can leave it as is for this PR, but we should already have the Node.js binary at this point, so we might want to consider not re-downloading it.
| # builds_to_upload routes their post IDs through create_draft_github_release, so | ||
| # publish_release flips them to External exactly like the app builds. Skipped when no | ||
| # bundles are present (e.g. a local app-only distribute run that didn't build them). | ||
| if Dir.exist?(STANDALONE_BUNDLES_FOLDER) |
There was a problem hiding this comment.
Why fail gracefully here? If we're committing to publishing the standalone CLI, then it seems like we might want a hard failure if the build artifacts are missing
| # The CDN exposes the SHA-256 only as build metadata, not as a downloadable | ||
| # sidecar, so checksum verification applies to STUDIO_CLI_URL sources (which do | ||
| # ship one). The CDN path relies on HTTPS for transport integrity plus the | ||
| # staging-extraction guard below. | ||
| if [ "$HAS_SHA256_SIDECAR" = "1" ]; then | ||
| download "${BUNDLE_URL}.sha256" "$TMP_BUNDLE.sha256" | ||
| echo "Verifying checksum..." | ||
| if ! verify_checksum "$TMP_BUNDLE" "$TMP_BUNDLE.sha256"; then | ||
| echo "Error: checksum verification failed. Aborting; existing install left untouched." >&2 | ||
| exit 1 | ||
| fi | ||
| fi |
There was a problem hiding this comment.
So, [ "$HAS_SHA256_SIDECAR" = "1" ] is effectively only true in a dry run or local testing context. Is it really still worth keeping..?
There was a problem hiding this comment.
Pull request overview
This PR extends Studio’s release/distribution flow so the standalone Studio CLI bundles are published to the WordPress.com Apps CDN for every build (dev/nightly, beta, stable), and updates the curl/PowerShell installers to install from the CDN latest (or a pinned STUDIO_CLI_VERSION) instead of a custom releases host.
Changes:
- Update standalone installers (
install.sh/install.ps1) to resolve bundles via Apps CDNlatest(orSTUDIO_CLI_VERSION), while keepingSTUDIO_CLI_URLas an override. - Add Fastlane support to upload the 6 standalone CLI bundles to the Apps CDN and fold their post IDs into the existing release visibility-flip flow.
- Build and persist standalone CLI bundle artifacts in Buildkite (macOS/Linux steps, Windows via
build-for-windows.ps1) and document the updated release process.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| scripts/standalone/install.sh | Switch default install source to Apps CDN latest/version pin, keep STUDIO_CLI_URL override. |
| scripts/standalone/install.ps1 | Same as install.sh, for Windows PowerShell installs. |
| scripts/create-standalone-bundle.ts | Rename bundle output to .tgz (and corresponding .sha256). |
| fastlane/Fastfile | Add Apps CDN upload lane + helper to publish CLI bundles and include them in release distribution. |
| docs/release-process.md | Document the new Apps CDN publishing flow and installer resolution behavior. |
| .buildkite/release-build-and-distribute.yml | Build/upload CLI bundle artifacts in release pipeline and download them for publishing. |
| .buildkite/pipeline.yml | Build/upload CLI bundle artifacts in dev pipeline and download them for distribution. |
| .buildkite/commands/build-for-windows.ps1 | Build the standalone CLI bundle during Windows builds. |
Comments suppressed due to low confidence (1)
scripts/standalone/install.ps1:92
- Checksum verification was removed entirely. Since the bundle build still generates a
.sha256sidecar, it would be good to keep checksum validation whenSTUDIO_CLI_URLpoints at a local directory or mirror that provides*.sha256, before extracting into the staging directory.
$TmpBundle = Join-Path $StagingDir $BundleName
Write-Host "Downloading Studio CLI..."
Get-Bundle -Url $BundleUrl -Dest $TmpBundle
Write-Host "Installing to $InstallDir..."
$ExtractDir = Join-Path $StagingDir "extracted"
New-Item -ItemType Directory -Path $ExtractDir -Force | Out-Null
# Use the Windows-provided BSD tar explicitly: a GNU tar earlier on PATH
# (e.g. Git Bash) would misread "C:" in the archive path as a remote host.
& "$env:SystemRoot\System32\tar.exe" -xzf $TmpBundle -C $ExtractDir
if ($LASTEXITCODE -ne 0) {
throw "Failed to extract $BundleName (tar exited with $LASTEXITCODE)"
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@bcotrim one follow-up concern now that this landed: I wonder if it is worth it to add a follow-up that either builds each bundle on native OS/arch runners or extracts the generated |
Related issues
WordPress.com Studio CLIApps CDN product)How AI was used in this PR
AI helped map the existing Apps CDN / Fastlane / Buildkite release flow, design the CLI upload to mirror the established PHP CLI binary path, switch the installers to the CDN
latestalias, and verify the work locally (Ruby + YAML syntax, the fastlane helper tests, astudio_cli_cdn_builds/upload dry-run harness, an end-to-endinstall.shbehavior harness, and a real throwaway upload against the production CDN). All changes were reviewed and validated before pushing.Proposed Changes
Makes the standalone Studio CLI available to users without the desktop app, kept current automatically.
WordPress.com Studio CLIproduct), for nightly/dev, beta, and stable alike. The bundles track the app build exactly — same version and visibility — so stable bundles become public at publish time just like the app, and there's no separate step to run.latestalias, so no bespoke redirect service is needed.STUDIO_CLI_VERSIONpins a specific version, andSTUDIO_CLI_URLis retained as a bypass for local builds and mirrors. Both paths rely on HTTPS plus a staged-extraction guard (a corrupt download fails attar -xzfbefore touching an existing install); the bundle's SHA-256 is still recorded as CDN build metadata.studio-cli-<platform>-<arch>.tgz(gzipped tar) for all six platform/arch targets.Trade-off / remaining dependency: the
install.sh/install.ps1scripts themselves still need public hosting for thecurl … | bash/irm … | iexentry points (the CDN serves uploaded builds, not arbitrary scripts) — a separate WordPress.com-side task. Until that lands, the CLI is installable via the direct CDN URL orSTUDIO_CLI_URL.Testing Instructions
Fastlane (dry run, no remote side effects):
Confirm it lists the six platform/arch uploads with the right product, platform labels, version, and sha. Existing helper tests still pass:
bash .buildkite/commands/run-fastlane-tests.sh.Real CDN upload (verified): a throwaway
0.0.1/ Internal build was uploaded to the productionWordPress.com Studio CLIproduct via the samemedia/newendpoint the lane posts to — confirming the upload path works and that the.tgzfile type is accepted (see Notes).Installer —
STUDIO_CLI_URLbypass:Installer — default CDN mode: with bundles published, a fresh install resolves
https://appscdn.wordpress.com/downloads/wordpress-com-studio-cli/<slug>/latest/full-install(e.g.
mac-silicon), andSTUDIO_CLI_VERSION=v1.11.0pins that version.Windows:
install.ps1mirrors the same logic (win32 →windows-x64/windows-arm64). It was validated structurally but needs a real Windows run to confirm (nopwshlocally).Pre-merge Checklist
Notes for reviewers
.tgz, not.tar.gz. The Apps CDN's upload validation (WordPresswp_check_filetype_and_ext) rejects the.tar.gzdouble extension — even thoughgzis allow-listed — while.tgz(same gzip bytes, single extension, already on the CDN's accepted-mime list) uploads cleanly.tar -xzfhandles both identically, so the installers and extraction logic are unchanged.install.shclearscom.apple.quarantinefrom the extracted files. The bundled.nodemodules are unsigned, so a browser-downloaded bundle would otherwise be Gatekeeper-blocked ("library load disallowed by system policy"). Thecurl … | bashpath isn't quarantined, so this is defensive for manual / MDM-managed installs. (Signing + notarizing the macOS bundle is a possible future hardening, tracked separately.)fs-ext-extra-prebuiltships both arches per-OS, and the target Node binary is downloaded per arch. Only cross-OS needs a native runner, which the matrix already provides.create_draft_github_release→make_cdn_builds_publicpath — no change to that logic.