Publish standalone CLI bundles to Apps CDN and install from the CDN latest alias

[bcotrim]

Related issues

• Related to STU-1780
• Builds on Add curl installer scripts for standalone CLI distribution #3064 (standalone bundling + curl installers) and Automattic/wpcom#221531 (adds the WordPress.com Studio CLI Apps 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 latest alias, and verify the work locally (Ruby + YAML syntax, the fastlane helper tests, a studio_cli_cdn_builds/upload dry-run harness, an end-to-end install.sh behavior 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.

• Every Studio build now publishes the standalone CLI bundles to the Apps CDN (under the WordPress.com Studio CLI product), 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.
• The curl installers download straight from the CDN's versionless latest alias, so no bespoke redirect service is needed. STUDIO_CLI_VERSION pins a specific version, and STUDIO_CLI_URL is retained as a bypass for local builds and mirrors (that path keeps .sha256 sidecar verification; the CDN path relies on HTTPS plus a staged-extraction guard, since the CDN exposes the checksum only as build metadata).
• Bundles are published as studio-cli-<platform>-<arch>.tgz (gzipped tar) for all six platform/arch targets.

Trade-off / remaining dependency: the install.sh / install.ps1 scripts themselves still need public hosting for the curl … | bash / irm … | iex entry 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 or STUDIO_CLI_URL.

Testing Instructions

Fastlane (dry run, no remote side effects):

npm run cli:bundle -- darwin arm64          # build a bundle (repeat per platform/arch)
DRY_RUN=true bundle exec fastlane publish_studio_cli_binaries version:"v1.11.0"

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 production WordPress.com Studio CLI product via the same media/new endpoint the lane posts to — confirming the upload path works and that the .tgz file type is accepted (see Notes).

Installer — STUDIO_CLI_URL bypass (checksum-verified):

STUDIO_CLI_HOME="$(mktemp -d)" STUDIO_CLI_URL="$PWD/standalone-bundles" bash scripts/standalone/install.sh

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), and STUDIO_CLI_VERSION=v1.11.0 pins that version.

Windows: install.ps1 mirrors the same logic (win32 → windows-x64 / windows-arm64). It was validated structurally but needs a real Windows run to confirm (no pwsh locally).

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors? — N/A (changes are Fastlane/Ruby, Buildkite YAML, PowerShell/shell installers, and docs; no app code).

Notes for reviewers

• Bundles are .tgz, not .tar.gz. The Apps CDN's upload validation (WordPress wp_check_filetype_and_ext) rejects the .tar.gz double extension — even though gz is allow-listed — while .tgz (same gzip bytes, single extension, already on the CDN's accepted-mime list) uploads cleanly. tar -xzf handles both identically, so the installers and extraction logic are unchanged.
• macOS quarantine: install.sh clears com.apple.quarantine from the extracted files. The bundled .node modules are unsigned, so a browser-downloaded bundle would otherwise be Gatekeeper-blocked ("library load disallowed by system policy"). The curl … | bash path isn't quarantined, so this is defensive for manual / MDM-managed installs. (Signing + notarizing the macOS bundle is a possible future hardening, tracked separately.)
• Cross-arch bundles are safe within an OS (so the existing CI matrix runners are fine): the CLI uses no-fsevents chokidar, fs-ext-extra-prebuilt ships 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.
• Stable bundles flip to public automatically because their CDN post IDs ride the draft GitHub release through the existing create_draft_github_release → make_cdn_builds_public path — no change to that logic.

[wpmobilebot]

📊 Performance Test Results

Comparing b55027b vs trunk

app-size

Metric	trunk	b55027b	Diff	Change
App Size (Mac)	2328.96 MB	2328.96 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	b55027b	Diff	Change
load	1797 ms	1724 ms	73 ms	🟢 -4.1%

site-startup

Metric	trunk	b55027b	Diff	Change
siteCreation	8560 ms	8529 ms	31 ms	⚪ 0.0%
siteStartup	3899 ms	3867 ms	32 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)