Repository navigation
Conversation
Add pnpm docs:archive:sync and a daily workflow that archives every LibreChat release and release candidate newer than the newest snapshot, each from the last docs commit before it was published, and opens a PR. Candidate snapshots stay until their final release is archived and are removed in that PR.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 80200df157
ℹ️ 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".
| const pending = releases | ||
| .filter((release) => RELEASE_TAG_PATTERN.test(release.tag)) | ||
| .filter((release) => !existing.includes(release.tag)) | ||
| .filter((release) => !newestArchived || isNewer(release.tag, newestArchived)) |
There was a problem hiding this comment.
When release streams overlap, an archived candidate for a higher version prevents a lower version's final release from ever being archived. For example, with v0.8.9-rc1 and v0.9.0-rc1 already archived, publishing v0.8.9 produces { archive: [], remove: [] }: this filter excludes the final release before stableIds can recognize it. Consequently, its candidate remains indefinitely and the latest stable docs remain outdated. Allow missing final releases that supersede existing candidate snapshots even when they sort below the newest archived version.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 7881ef3 (pushed head ba9d8ee). Final releases are now compared with the newest archived final release, not the newest snapshot of any kind, so with v0.8.8, v0.8.9-rc1 and v0.9.0-rc1 archived, publishing v0.8.9 archives it and removes v0.8.9-rc1 while v0.9.0-rc1 stays. Unit test 'archives a final release below a newer archived candidate' is your example; the final-release-replaces-its-candidate-snapshots scenario runs the planner through the real script.
|
|
||
| /** The last commit on `ref` at or before `timestamp`, so a snapshot matches its release day. */ | ||
| export async function commitAt(timestamp: string, cwd: string, ref = 'HEAD'): Promise<string> { | ||
| const { stdout } = await execFile('git', ['rev-list', '-1', `--before=${timestamp}`, ref], { |
There was a problem hiding this comment.
If a branch contains commits dated before a release but is merged into main afterward, this unrestricted traversal can select a commit from that branch rather than the tree that was actually on main at release time. The resulting archive can therefore include unpublished changes and omit other main-branch changes. Git's rev-list documentation specifies that --first-parent will “follow only the first parent commit upon seeing a merge commit”; use that restriction when resolving the historical main-branch snapshot.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
| } | ||
|
|
||
| async function fetchReleases(repository: string, token?: string): Promise<Release[]> { | ||
| const response = await fetch(`https://github.com/proxy/api.github.com/repos/${repository}/releases?per_page=50`, { |
There was a problem hiding this comment.
If an unarchived release falls beyond the first 50 API results—for example, after an extended interruption in syncing—this function silently omits it. GitHub documents per_page as the number of results per page and defaults page to 1, so this request does not retrieve the complete release list. Once the returned newer releases are archived, the planner's newest-snapshot cutoff permanently excludes the omitted releases on subsequent runs. Follow pagination until all potentially pending releases have been fetched rather than treating the first page as complete. See the List releases parameters.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 7881ef3 (pushed head ba9d8ee): fetchReleases follows page= at 100 per page until a short page, and fails after 20 full pages instead of treating a partial list as complete. Unit test 'follows pagination to the last page and skips drafts' (6819aea) checks two requests and the release on page 2.
📦 Next.js Bundle Analysis for librechat.aiThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
Compare final releases with the newest archived final release, so an archived candidate of a newer version no longer holds back the final release of an older one. Pick the release-day commit from main's first-parent history, read every page of releases, refuse to start without a final release snapshot, and stop before the archive outgrows what the build can bundle. Archived release candidates newer than the latest release now get a release candidate banner instead of the no longer maintained warning, and the sync and the archived versions each get scenario specs.
📦 Next.js Bundle Analysis for librechat.aiThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
Summary
Archiving docs for a LibreChat release was a manual
pnpm docs:archiverun, andv0.8.9-rc1(published Oct 26) still has no snapshot. This addspnpm docs:archive:syncand a dailySync docs archiveworkflow that does it automatically and opens a PR for review.Each new release and release candidate is archived from the last commit on
main(first-parent) before it was published, so a snapshot matches its release day. Candidate snapshots stay while a release is in testing and show a "Release candidate" banner instead of the "no longer maintained" warning; the PR that archives the final release removes them. Final releases are compared with the newest archived final, so overlapping release lines work. The run changes nothing when the releases API fails, when there is no release snapshot to start from, or when the archive would reach the 17 snapshots webpack cannot bundle.Change Type
Testing
pnpm exec vitest run scripts/sync-docs-archive.test.ts lib/docs-version-order.test.ts scripts/archive-docs-version.test.ts: all pass (planner rules, pagination, first-parent pick, banner kind)e2e/docs-archive-sync.spec.ts: 5 scenarios run the real script against a git fixture and a local releases API stand-ine2e/docs-archive-versions.spec.tsagainstnext starton a production build that included a generatedv0.8.9-rc1snapshot: every snapshot is listed in the switcher and shows the banner for its status; light and dark screenshots checkedpnpm docs:archive:sync --dry-runagainst the live releases plansv0.8.9-rc1from2426cdc7, committed 30 seconds before the release. The snapshot is not committed here; the workflow opens it after merge.pnpm typecheck, ESLint and Prettier cleanChecklist