[tellaho]

Overview

Category: improvement

User Impact: The website can link to the current stable release's installers without querying the GitHub releases API.

Problem: The updater feed contains update archives rather than all user-facing installers, and release-hosted JSON cannot be read directly by cross-origin website JavaScript.

Solution: Publish a complete five-installer downloads.json on a dedicated download-feed branch after each approved stable feed promotion, so the website offers the release installed stable apps receive. Previews and betas never change it. Raw GitHub serves the catalog with CORS support. Until the first stable promotion the URL returns 404 and the website should fall back to the releases page.

File changes

.github/workflows/desktop-stable-feed.yml
Publish the download catalog after stable feed promotion and read-back, in the same approved job.

scripts/download-manifest.mjs
Define and validate the versioned five-installer contract (channel: "stable", X.Y.Z only) against actual nonempty assets of a non-prerelease release.

scripts/publish-desktop-downloads.mjs
Follow stable-feed/latest.json. Provide a read-only default and explicit apply mode. Create the isolated data branch initially, update with the existing file SHA, reject rollback, and verify read-back.

tests/integration/desktop-downloads.test.mjs
Exercise creation, updates, dry runs, recovery, malformed assets, prerelease/beta/preview rejection, conflicting writes, and workflow ordering; assert preview promotion never publishes it.

docs/releases.md
Document the public schema, publication/recovery commands, caching and retention.

Reproduction steps

1. After merge and the first approved desktop-stable-feed.yml run (e.g. -f version=1.0.0), the job publishes https://github.com/raw/block/buzz-app/download-feed/downloads.json.
2. From an authenticated checkout, GH_REPO=block/buzz-app bin/node scripts/publish-desktop-downloads.mjs 1.0.0 prints all five exact installer URLs without writing anything; --apply recovers the current promoted stable version.
3. Verify an anonymous browser can read that URL and navigate to both DMGs, the Windows installer, AppImage and DEB.

Validation

• Originally preview-only (validated at 943b976ae against promoted 0.7.0-preview.260.1). Retargeted to the stable track at 21a36c4d1 per review; preview cleanup changes were dropped because stable releases are never pruned.
• At 21a36c4d1: full Node integration suite 307/309 passed, one skipped, one failed: macOS launchers preserve icon, port, explicit config and runner arguments, the same pre-existing fixture failure seen on base. The workflow-ordering test fails if the stable feed job stops publishing.
• Pre-commit and pre-push hooks passed.
• No stable release exists yet, so the live dry run, Actions-token write path and anonymous read remain to be checked at the first stable promotion. No data branch or release was changed during validation.

[tellaho]

🤖 Review round 1

No blocking issues. The order is right: publish runs after the feed read-back and before cleanup, and cleanup refuses to run without valid download metadata. Rulesets don't cover download-feed, and the step reuses the job's existing contents: write token.

• Low: a failed publish runs after the updater feed has already advanced. The run goes red and cleanup is skipped, so the website stays on the previous installers. That's the intended fail-closed path, and it's documented. No change needed.
• Low: rollback is rejected by design. Promoting an older build to recover the feed would fail the publish step. The docs already say to recover by promoting a higher build. No change needed.
• Low: test volume. Tests are about 52% of the additions. Consolidate overlapping publisher scenarios and repeated setup, keeping the distinct failure modes.
• CI: the current failures (a Rust credential-peer test and three browser-journey shards) are outside this diff. Failed jobs are rerunning.

[kalvinnchau]

🤖 Review at 43b303654, against current main (b3ed2397b). The branch base bd344a52d predates #3150. git merge-tree reports no conflicts, but the merged result is broken.

[P1] Automatic promotions pass an empty version: .github/workflows/release.yml:357
The new step uses VERSION: ${{ inputs.promote_version || needs.build.outputs.version }}. #3150 renamed that job to desktop. After the merge, promote_preview has needs: [desktop], and the preceding feed step uses needs.desktop.outputs.version.

On automatic (non-dispatch) runs, VERSION is empty, so assert.match(version, previewVersionPattern) throws. This happens after the updater feed has already moved:

• the job fails;
• downloads.json is never published;
• cleanup (if: success()) is skipped, so previews accumulate.

Manual promote_version dispatches are unaffected. Fix: rebase onto main and use needs.desktop.outputs.version.

[P2] The workflow-ordering test passes even when the order is wrong after rebase: tests/integration/desktop-downloads.test.mjs:136-140
The test locates read-back via a step whose run contains cmp "$RUNNER_TEMP/candidate/latest.json". On main, that cmp now lives in scripts/promote-updater-feed.sh, so findIndex returns -1 and publication > -1 is always true. The test also does not check the VERSION expression.

I ran desktop-downloads.test.mjs and desktop-release.test.mjs on the merged tree with dependencies freshly installed: 15/15 passed despite the P1. Fix: anchor on the promote-updater-feed.sh preview-feed step, and assert that the publish step uses the same VERSION expression as the feed step.

[P2, needs a decision] downloads.json remains preview-only after the stable lane: scripts/download-manifest.mjs:27,37,48
validateDownloadManifest and buildDownloadManifest hard-code channel: "preview" and prerelease: true. installerUrls accepts only preview versions. Only release.yml writes the file; desktop-stable.yml and desktop-stable-feed.yml do not.

Once v1.0.0 is marked Latest, the single public downloads.json will still direct website downloads to previews. Changing that later requires a schema change and an update to the prune validator.

If the website should follow stable, add a channel key or a separate stable file, written by the stable-feed dispatch. If preview-only is intended, document that in docs/releases.md.

Scores: minimalness 9/10, elegance 8/10, correctness 5/10.

• Elegance: this adds a third copy of the preview-version regex (also in preview-feed.mjs and promote-updater-feed.sh), and the schema fixes channel.
• Correctness: the P1 breaks every automatic promotion once merged.

Not approved.

[matt2e]

🤖 Addressed the review at 43b303654 in fbdd12331, rebased onto current main (b3ed2397b, which includes #3150).

Fixed

• P1 – empty VERSION on automatic promotions (.github/workflows/release.yml): the publish-downloads step now uses ${{ inputs.promote_version || needs.desktop.outputs.version }}, the same expression as the updater-feed step. That was the only stale needs.build reference this PR added.
• P2 – vacuous workflow-ordering test (tests/integration/desktop-downloads.test.mjs): the test now anchors on the promote-updater-feed.sh preview-feed step, asserts that the feed, publish and prune steps all exist (index ≥ 0) and run in that order, and asserts the publish step's VERSION matches the feed step's. Checked that the new assertions fail against the old needs.build expression and pass after the fix.

Tests on the rebased tree: desktop-downloads 6/6, desktop-release 9/9, prune-preview-releases 7/7, preview-feed passing (28/28 across the four files).

Not changed

• P2 – downloads.json stays preview-only: needs a product decision (channel key / separate stable file vs. documenting preview-only). Happy to take either direction once decided.
• Third copy of the preview-version regex: preview-feed.mjs keeps its own on purpose — its test copies that script alone into a temp directory, so a sibling import wouldn't resolve (see 43b3036's message). The prune script already imports the shared pattern.