feat: show newer pre-release on downloads page (robust, from real assets)#62
Conversation
v4/v5 still target Node 20, which the runners now force onto Node 24 with a deprecation warning. v5/v6 are the Node-24-native majors and clear it.
… assets
The downloads page only showed the latest stable (prereleases were filtered
out), and update-downloads.py generated links by substituting the version
number into a fixed template — which breaks when asset naming changes (v0.14
ships 'tauri' builds and moved macOS to arm64, so substitution would produce
dead -macos-x86_64.dmg links).
Rewrite update-downloads.py to build each platform's links from the release's
actual assets, and emit a 'prerelease' block whenever the latest pre-release
is newer than the latest stable. downloads.yml is now {stable, prerelease?};
downloads.pug renders a 'Pre-release: vX' section when present. Package-manager
and Play Store links stay on the stable block only.
Verified: all 14 generated GitHub asset URLs return 200, including the
v0.14.0b1 arm64 macOS builds.
Greptile SummaryThis PR updates the downloads page to show a newer prerelease when one exists. The main changes are:
Confidence Score: 4/5The changed download data path needs fixes before merging.
scripts/update-downloads.py, _includes/download-url.js, _includes/schema-index.html Important Files Changed
Reviews (1): Last reviewed commit: "feat: show newer pre-release on download..." | Re-trigger Greptile |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e1db6dced8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| platforms: | ||
| # Generated by scripts/update-downloads.py — do not edit by hand. | ||
| stable: |
There was a problem hiding this comment.
Update remaining download data consumers
Because the downloads data now lives under stable, the existing consumers that still read site.data.downloads.version and site.data.downloads.platforms lose their inputs. On the homepage download button, _includes/download-url.js parses the missing platforms value and then calls .filter(...), so visitors with a detected OS hit a JS error instead of getting a direct platform download; _includes/schema-index.html also emits an empty software version and no per-platform entry points. Please either preserve the old top-level aliases or update those includes to read site.data.downloads.stable.*.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in e4749b4. Updated _includes/download-url.js (download button) and _includes/schema-index.html (JSON-LD) to read site.data.downloads.stable.*. Verified no flat downloads.version/downloads.platforms references remain anywhere in the repo.
| raise SystemExit("No stable release found") | ||
| latest_stable = stable[-1] | ||
|
|
||
| data = {"stable": build_block(latest_stable, include_packages=True, with_android=True)} |
There was a problem hiding this comment.
Nested Downloads Break Consumers
When this script writes only stable and prerelease, the existing homepage schema and download-button include still read site.data.downloads.version and site.data.downloads.platforms. After regeneration, those old keys are missing, so the JSON-LD loses its version/download entries and the site-wide download CTA can fail when it tries to filter a null platform list.
There was a problem hiding this comment.
Fixed in e4749b4. Updated _includes/download-url.js (download button) and _includes/schema-index.html (JSON-LD) to read site.data.downloads.stable.*. Verified no flat downloads.version/downloads.platforms references remain anywhere in the repo.
| token = os.getenv("GITHUB_TOKEN") | ||
| if token: | ||
| headers["Authorization"] = f"Bearer {token}" | ||
| releases = requests.get(API, headers=headers, timeout=30).json() |
There was a problem hiding this comment.
When GitHub returns a JSON error body for a rate limit, auth failure, or transient server error, this line still decodes it and the next filter treats the object keys as release records. The scheduled pages workflow can then crash at r["draft"] instead of reporting the HTTP failure clearly or keeping generation deterministic.
There was a problem hiding this comment.
Fixed in e4749b4. Added resp.raise_for_status() and an isinstance(releases, list) guard, so a GitHub API error body (rate-limit/auth/5xx) now fails loudly instead of being parsed as releases and crashing at r['draft'].
…rrors Address review on #62: - download-url.js (homepage download button) and schema-index.html (JSON-LD) still read the old flat site.data.downloads.version/.platforms, which the stable/prerelease split removed — point them at .stable.* so the CTA and schema keep working. - update-downloads.py: raise_for_status() + validate the response is a list, so a GitHub API error body (rate-limit/auth/5xx) fails loudly instead of being parsed as releases and crashing at r['draft'].
What
The /downloads/ page only shows the latest stable (v0.13.2);
v0.14.0b1is filtered out as a prerelease. This adds a Pre-release section whenever the newest prerelease is newer than stable.Why the rewrite
The old
update-downloads.pybuilt links by substituting the version number into a fixed template. v0.14 changed asset naming (activitywatch-tauri-...) and moved macOS to arm64, so substitution would have produced dead-macos-x86_64.dmglinks. The rewrite builds each platform's links from the release's actual assets (preferring the plain non-tauri builds), so it survives naming changes — and future-proofs stable for when it moves to v0.14._data/downloads.ymlis now{ stable, prerelease? }.downloads.pugrenders a "Pre-release: vX" section (with an instability note) whenprereleaseis present.Verification
Ran the script against the live API and HEAD-checked all 14 generated GitHub asset URLs → all 200, including the v0.14.0b1 Apple Silicon macOS builds. CI build will confirm the pug/Liquid render.
Note: for v0.14 (which ships both classic and
tauribuilds) this shows the classicactivitywatch-*builds for consistency with stable; easy to flip to tauri if preferred.