feat(changelogs): unified OS releases stream with stable-daily, LTS, …#736
Conversation
…Dakota placeholder - Upgrade fetch-feeds.js from Atom XML (~10 items) to GitHub Releases API (100 items paginated) with GITHUB_TOKEN auth and 24h file-mtime cache - Add dual-mode Markdown/HTML parser in parseOsRelease.ts — GitHub API returns Markdown bodies; Atom feed returns HTML; format auto-detected - Extend OsStream type: "stable" | "stable-daily" | "lts" | "dakota" - detectStream() maps stable-* prefixed tags to "stable-daily" - FirehoseFeed.tsx: pinned "Current Versions" section with Bluefin stable, Bluefin LTS, and Bluefin Dakota placeholder cards at top of changelogs - Unified "Updates Stream" interleaves OS releases with app updates - OsReleaseCard.tsx: stream-aware title, badge, and mascot per stream - OsReleaseCard.module.css: Dakota card (purple accent + dakotaraptor), badgeDaily, badgeDakota; fix chip/mascot overlap with padding-right Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the release fetching process to utilize the GitHub API with an Atom feed fallback and introduces a 24-hour caching mechanism. The UI now features a unified chronological "Updates Stream" and supports new release streams, including "stable-daily" and "dakota". Additionally, the release parser has been updated to handle both Markdown and HTML formats. Feedback was provided regarding the lack of pagination in the GitHub API implementation, which may lead to missing releases if the volume of daily builds is high.
| const url = `https://api.github.com/repos/${owner}/${repo}/releases?per_page=${perPage}`; | ||
|
|
||
| console.log(`Fetching releases API: ${url}`); | ||
| const response = await fetch(url, { | ||
| headers: { | ||
| Authorization: `Bearer ${token}`, | ||
| Accept: "application/vnd.github+json", | ||
| "X-GitHub-Api-Version": "2022-11-28", | ||
| }, | ||
| }); | ||
|
|
||
| if (!response.ok) { | ||
| console.warn(`GitHub API returned ${response.status} for ${owner}/${repo} — falling back to Atom`); | ||
| return null; | ||
| } | ||
|
|
||
| const releases = await response.json(); |
There was a problem hiding this comment.
The implementation does not actually perform pagination, despite the pull request description stating '100 items paginated'. It currently makes a single request with a limit of 100 items. If the repository exceeds 100 releases, or if you need to look further back to find stable releases among a high volume of daily builds, this will fail to retrieve them. To fulfill the requirement of ensuring stable releases aren't pushed out of the feed, you should implement a loop that follows the Link header provided by the GitHub API to fetch multiple pages if necessary.
Single-page fetch (100 items) allowed daily builds to push stable releases out of the feed window. Now follows rel="next" Link headers until exhausted or the 500-release cap is reached. Adds parseLinkNext() helper and replaces the single fetch call with a pagination loop. The 24h file-mtime cache and Atom fallback are unchanged. Assisted-by: Claude Sonnet 4.6 via GitHub Copilot Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1 participant
…Dakota placeholder