feat: Update StudioCMS configuration and documentation for beta.31#177
Conversation
- Added `db` configuration option to define database dialect in `studiocms.config.mjs`. - Updated translation guide to reflect new translation directory structure. - Enhanced CLI documentation with new `migrate` command for managing database migrations. - Revised integration documentation to clarify the use of Astro DB and its components. - Updated SDK documentation to specify the use of Kysely database client. - Improved plugin documentation with updated hooks and minimum version requirements. - Refined getting started guide to include new database connection options and environment variables. - Added badges to various documentation pages to indicate updates.
📝 WalkthroughWalkthroughAdds GitHub Actions to build/publish multi-arch Docker images and call DokPLOY, a multi-stage Dockerfile and nginx config, numerous docs and UI/component updates, schema and package catalog additions (hidden flag, new entries), tooling/CI tweaks (tokenized changelog fetch, bearer auth), and contributor utilities adjustments. Changes
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub Actions
participant Repo as Repository
participant Buildx as Docker Buildx/QEMU
participant GHCR as GHCR (ghcr.io)
participant Dok as DokPLOY API
GH->>Repo: checkout repository
GH->>Buildx: setup QEMU & Buildx
GH->>Repo: restore pnpm cache
GH->>GHCR: docker login (GITHUB_TOKEN)
GH->>Buildx: build-and-push (multi-arch, cache, tags)
Buildx-->>GHCR: push image manifests (latest, sha, ref)
GH->>GHCR: verify/print pushed refs
GH->>Dok: POST compose.update { imageRef } (PUBLIC_GITHUB_TOKEN)
Dok-->>GH: respond (update output -> GITHUB_OUTPUT)
GH->>Dok: POST compose.deploy { description: commit SHA } (PUBLIC_GITHUB_TOKEN)
Dok-->>GH: respond (deploy output -> GITHUB_OUTPUT)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45–75 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Lunaria Status Overview🌕 This pull request will trigger status changes. Learn moreBy default, every PR changing files present in the Lunaria configuration's You can change this by adding one of the keywords present in the Tracked Files
Warnings reference
|
…o 'cloudinary-js'
…i18n options; add Kysely migration guide
… and update upgrade guide for Beta.31
…move deprecated web vitals entries
…de guide for version 0.1.0-beta.31
Adammatthiesen
added
the
dokploy-preview
Adammatthiesen
added
dokploy-preview
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (9)
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-18.mdx (1)
11-14: Drop unusedReadMoreimport (or use it).
ReadMoreis imported but not referenced in the MDX body, which may trip lint/build checks or just add noise.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-20.mdx (1)
25-30: Remove or update[web-vitals-guide]reference—target page was removed in this PR.
PR objectives indicateen/package-catalog/community-plugins/web-vitals.mdxwas deleted, so this internal link reference likely goes stale/broken.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-19.mdx (1)
24-25: Update link to point to specific Web-Vitals plugin guide page.The reference
[web-vitals-guide]at line 39 points to/en/package-catalog/(the catalog root), but the actual dedicated guide exists at/en/package-catalog/community-plugins/web-vitals/. Update the link definition to direct readers to the specific plugin page instead of making them navigate from the catalog root.src/content/package-catalog/astrojs-web-vitals.json (1)
5-11: Broken docsLink in deprecated package entry.The
docsLinkon line 5 points to/package-catalog/community-plugins/web-vitals/which was removed according to the PR changes. While the package is hidden and won't be displayed, the broken link remains in the data.Consider either:
- Removing the
docsLinkfield for deprecated packages- Redirecting to the new
@withstudiocms/web-vitalsdocumentation- Creating a deprecation notice page
src/content/package-catalog/studiocms-web-vitals.json (1)
5-5: Broken link:docsLinkreferences deleted documentation.Line 5 points to
/package-catalog/community-plugins/web-vitals/, but per the PR objectives, the documentation pageen/package-catalog/community-plugins/web-vitals.mdxhas been deleted. This will result in a 404 when the link is accessed. Either remove thedocsLinkfield entirely or update it to point to valid documentation.Consider removing the
docsLinkfield:- "docsLink": "/package-catalog/community-plugins/web-vitals/",Or, if there is alternative documentation to reference, update the link accordingly.
src/components/DropdownScript.astro (1)
1-10: Revert to generic import path — the client-specific path is not supported by the studiocms/ui API.The import has been incorrectly updated to
studiocms:ui/components/dropdown/client, but the official studiocms/ui API documentation specifies thatDropdownHelpershould be imported fromstudiocms:ui/components(the generic entrypoint). Change the import toimport { DropdownHelper } from 'studiocms:ui/components';. The same issue affectsModalScript.astroandToasterScript.astro, which also use the unsupported/clientsub-paths.src/starlight-sidebar/en.json (1)
1-22: Addcustom-frontendkey to all locale files for i18n consistency.
The key was added toen.jsonbut is missing fromde.json,es.json,fr.json,ko.json, andzh-cn.json. While the i18n fallback mechanism (intranslate.ts) automatically falls back to English when a key is missing, it's best practice to include all keys across all locales for complete translation coverage and to avoid relying on fallback behavior.src/content/docs/en/config-reference/index.mdx (1)
23-33: Fix inconsistent PostgreSQL dialect name ingetting-started.mdx.The
getting-started.mdxuses'postgres'as the dialect name (line 277), butconfig-reference/index.mdx(line 66) and the upgrade guide0-1-0-beta-31.mdxboth document it as'postgresql'. This inconsistency will cause users copying examples to encounter errors. Updategetting-started.mdxline 277 to use'postgresql'to match the canonical reference documentation.src/content/docs/en/plugins/renderers.mdx (1)
31-50: Change the hook key fromstudiocms:renderingtostudiocms:astro:config.The example code will fail silently with the current hook key. According to StudioCMS documentation, custom renderer registration uses the
studiocms:astro:confighook (notstudiocms:rendering), with the samesetRenderingcallback pattern shown. Also verify the minimum version—documentation examples show0.1.0, not0.1.0-beta.31.
🧹 Nitpick comments (11)
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-22.mdx (1)
19-19: Link now points to the catalog root; consider linking to the specific replacement entry.The “Web Vitals Guide” reference now goes to
/en/package-catalog/, which is less direct than a dedicated guide/page. If there’s an entry for@studiocms/web-vitals(or an anchor section), linking to that specific target would improve UX and reduce confusion. (Not flagging as broken—just specificity.) Based on learnings, verify the target page/slug exists before changing again.Also applies to: 44-44
src/starlightOverrides/Search.astro (3)
24-25: Justify the nullish-coalescing assignment suppression.The
noAssignInExpressionslint rule typically discourages assignments within expressions, butdict.modal ??= {}is a legitimate pattern for conditional initialization. Verify that this rule suppression is necessary for your linting configuration. If the assignment pattern is fundamentally at odds with your coding standards, consider refactoring:- // biome-ignore lint/suspicious/noAssignInExpressions: <explanation> - let pointer = (dict.modal ??= {}); + if (!dict.modal) { + dict.modal = {}; + } + let pointer = dict.modal;Alternatively, if the current pattern aligns with your team's preferences, provide a meaningful explanation in the suppression comment beyond
<explanation>.
67-68: Mitigate type-safety bypass with proper typing.The
@ts-expect-errorsuppression at line 67 sidesteps type checking. Thedataset.translationsattribute is untyped, leading to the workaround. Consider defining a type for the sl-doc-search custom element or using a more type-safe extraction:- // @ts-expect-error todo: add proper type casting - const translations = JSON.parse(document.querySelector('sl-doc-search').dataset.translations); + const searchElement = document.querySelector('sl-doc-search') as HTMLElement; + const translations = JSON.parse(searchElement?.dataset.translations ?? '{}');
13-39: Add error handling for translation processing.The translation processing pipeline (lines 13–39) assumes well-formed input and does not validate the key structure or handle edge cases:
- No validation that
key.split('.')produces expected segments- No safeguards if translation values are null/undefined
- Silent failures if exceptions list is misconfigured
Consider adding defensive checks:
.reduce((dict, [key, val]) => { const exceptions = ['button', 'shortcutLabel', 'placeholder']; const segments = key.split('.'); + + if (!val || segments.length === 0) { + return dict; // Skip invalid entries + } if (exceptions.includes(key)) {src/pages/404.astro (1)
6-6: Minor formatting inconsistency: extra spaces before closing braces.The frontmatter object has extra spaces before the closing
}}. Consider removing them for consistency.Apply this diff:
-<StarlightPage frontmatter={{ title: '404', template: 'splash' }}> +<StarlightPage frontmatter={{ title: '404', template: 'splash' }}>src/pages/[lang]/guides/upgrade/latest.astro (1)
84-97: Consider adding defensive handling for invalid semver versions.While the current logic works for well-formed versions, if all versions fail
semver.valid()checks,latestVersionwould remain assemverVersions[0], which might be an invalid semver string. Consider adding a fallback or validation.Example defensive approach:
// Find the latest version let latestVersion = semverVersions[0]; let latestIndex = 0; +let foundValid = false; for (let i = 0; i < semverVersions.length; i++) { const version = semverVersions[i]; if ( semver.valid(version) && (!semver.valid(latestVersion) || semver.gt(version, latestVersion)) ) { latestVersion = version; latestIndex = i; + foundValid = true; } } + +// Fallback if no valid semver versions found +if (!foundValid && semverVersions.length > 0) { + console.warn('No valid semver versions found, using first version'); +}src/content/docs/en/how-it-works/restapi.mdx (1)
9-14: Nice cleanup of outdated storage wording; consider linking to the “Database” guidance if relevant.
If the REST API’s backing store is now user-chosen (Kysely/etc.), a short pointer to the database guide can prevent confusion.src/content/docs/en/config-reference/features.mdx (1)
221-261: Verify nesting path and add type/default forsecurityobject.The upgrade guide (0-1-0-beta-31.mdx) references
features.dashboard.security.hideGeneratorTags, but this page documentsfeatures.dashboardConfig.security.hideGeneratorTags. Confirm which is correct and update the inconsistency. Additionally, thesecurityobject itself lacks a documented type and default value—only itshideGeneratorTagschild property is specified.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-31.mdx (1)
50-158: LGTM! Comprehensive migration guide.The migration steps provide a clear, progressive path from the old architecture to beta.31, with excellent use of Starlight components to organize the information. The dual approach (CLI and Web UI) offers flexibility for different user preferences.
Static analysis suggests minor style improvements:
- Lines 18, 22, 73: "Kysely based" → "Kysely-based" (compound adjective)
- Line 138: "To do this" could be more direct as "To use the migration tool"
These are optional stylistic refinements and don't affect clarity.
nginx.conf (1)
1-1: Consider using auto-detection for worker processes.A single worker process may underutilize multi-core systems. For better performance, consider using
worker_processes auto;to automatically match the number of CPU cores.-worker_processes 1; +worker_processes auto;src/starlightOverrides/PageSidebar.astro (1)
55-67: Document or extract the magic number multiplier.Line 63's "MAGIC NUMBER 🥲" comment indicates this
0.25multiplier was empirically determined. Consider extracting it to a CSS custom property with documentation explaining why this specific value is needed, or add a comment describing the calculation's purpose.For example:
/* Target 25% of available content width for right sidebar on large viewports */ --sl-sidebar-content-ratio: 0.25; .sl-container { max-width: calc( ( ( 100vw - var(--sl-sidebar-width) - 2 * var(--sl-content-pad-x) - 2 * var(--sl-sidebar-pad-x) ) * var(--sl-sidebar-content-ratio) ) ); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (70)
.github/workflows/ci-docker-main.yml(1 hunks).github/workflows/ci-docker-pr.yml(1 hunks).github/workflows/ci-knip.yml(2 hunks).github/workflows/ci-link-validator.yml(2 hunks).vscode/settings.json(1 hunks)Dockerfile(1 hunks)astro.config.mts(9 hunks)ec.config.mjs(1 hunks)knip.config.ts(1 hunks)nginx.conf(1 hunks)package.json(2 hunks)scripts/generate-release-notes.ts(1 hunks)scripts/lib/changelogs.ts(1 hunks)src/components/ContributorList.astro(2 hunks)src/components/DropdownScript.astro(1 hunks)src/components/ModalScript.astro(1 hunks)src/components/PackageCatalog.astro(2 hunks)src/components/ToasterScript.astro(1 hunks)src/content.config.ts(1 hunks)src/content/docs/en/config-reference/features.mdx(3 hunks)src/content/docs/en/config-reference/index.mdx(3 hunks)src/content/docs/en/config-reference/locale.mdx(3 hunks)src/content/docs/en/guides/contributing/translations.mdx(2 hunks)src/content/docs/en/guides/custom-frontend/rendering.mdx(2 hunks)src/content/docs/en/guides/index.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-16.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-17.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-18.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-19.mdx(2 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-20.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-21.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-22.mdx(2 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-23.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-24.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-25.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-26.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-27.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-28.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-29.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-30.mdx(1 hunks)src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-31.mdx(1 hunks)src/content/docs/en/how-it-works/cli.mdx(8 hunks)src/content/docs/en/how-it-works/index.mdx(1 hunks)src/content/docs/en/how-it-works/restapi.mdx(1 hunks)src/content/docs/en/how-it-works/sdk.mdx(2 hunks)src/content/docs/en/package-catalog/community-plugins/web-vitals.mdx(0 hunks)src/content/docs/en/package-catalog/studiocms-plugins/studiocms-devapps.mdx(2 hunks)src/content/docs/en/plugins/extended.mdx(2 hunks)src/content/docs/en/plugins/index.mdx(4 hunks)src/content/docs/en/plugins/renderers.mdx(3 hunks)src/content/docs/en/start-here/configuration.mdx(3 hunks)src/content/docs/en/start-here/environment-variables.mdx(3 hunks)src/content/docs/en/start-here/getting-started.mdx(17 hunks)src/content/docs/en/start-here/why-studioCMS.mdx(2 hunks)src/content/docs/en/utils/kysely-and-sdk.mdx(1 hunks)src/content/docs/en/utils/template-lang.mdx(1 hunks)src/content/i18n/en.json(1 hunks)src/content/package-catalog/astrojs-web-vitals.json(1 hunks)src/content/package-catalog/studiocms-web-vitals.json(1 hunks)src/content/package-catalog/withstudiocms-template-lang.json(1 hunks)src/pages/404.astro(1 hunks)src/pages/[...enRedirectSlug].astro(2 hunks)src/pages/[lang]/guides/upgrade/latest.astro(2 hunks)src/pages/index.astro(2 hunks)src/starlight-sidebar/en.json(1 hunks)src/starlightOverrides/AdBanner.astro(1 hunks)src/starlightOverrides/PageSidebar.astro(1 hunks)src/starlightOverrides/Search.astro(1 hunks)src/util/contributors.config.ts(4 hunks)src/util/getContributors.ts(2 hunks)
💤 Files with no reviewable changes (1)
- src/content/docs/en/package-catalog/community-plugins/web-vitals.mdx
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-07-21T12:16:32.374Z
Learnt from: ArmandPhilippot
Repo: withstudiocms/docs PR: 140
File: src/content/docs/fr/guides/upgrade/version-guides/0-1-0-beta-19.mdx:24-24
Timestamp: 2025-07-21T12:16:32.374Z
Learning: In the withstudiocms/docs repository, documentation URLs in the package-catalog may maintain legacy path names for stability and consistency across language versions, even when the actual package names have been updated. Always verify that corresponding files exist before flagging URLs as broken.
Applied to files:
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-22.mdxsrc/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-19.mdxsrc/content/i18n/en.jsonsrc/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-31.mdxscripts/generate-release-notes.tssrc/content/docs/en/guides/contributing/translations.mdxsrc/content/docs/en/start-here/getting-started.mdxsrc/content/package-catalog/withstudiocms-template-lang.jsonsrc/util/contributors.config.ts
📚 Learning: 2025-07-24T11:57:15.225Z
Learnt from: ArmandPhilippot
Repo: withstudiocms/docs PR: 149
File: src/content/docs/fr/guides/upgrade/version-guides/0-1-0-beta-21.mdx:13-15
Timestamp: 2025-07-24T11:57:15.225Z
Learning: In the withstudiocms/docs repository, when reviewing French translation files, maintain consistency with the English version even if it means keeping unused imports. Structural parity between language versions is prioritized over removing unused code.
Applied to files:
src/content/i18n/en.jsonsrc/content/docs/en/package-catalog/studiocms-plugins/studiocms-devapps.mdxsrc/content/docs/en/guides/contributing/translations.mdxsrc/content/package-catalog/withstudiocms-template-lang.json
📚 Learning: 2025-07-24T12:00:35.014Z
Learnt from: ArmandPhilippot
Repo: withstudiocms/docs PR: 149
File: src/content/docs/fr/guides/upgrade/version-guides/0-1-0-beta-20.mdx:18-18
Timestamp: 2025-07-24T12:00:35.014Z
Learning: In the withstudiocms/docs repository, while translations should maintain structural parity with English versions, improving readability during translation is acceptable when the original text has clear redundancy or readability issues that would also impact the translation quality. The maintainer ArmandPhilippot confirmed this approach is reasonable when the technical meaning is preserved.
Applied to files:
src/content/docs/en/guides/contributing/translations.mdx
📚 Learning: 2025-04-26T12:29:17.995Z
Learnt from: ArmandPhilippot
Repo: withstudiocms/docs PR: 130
File: src/content/docs/fr/guides/upgrade/version-guides/0-1-0-beta-17.mdx:1-11
Timestamp: 2025-04-26T12:29:17.995Z
Learning: When reviewing translations in the withstudiocms/docs repository, compare with the corresponding English version as the source of truth, not with other files in the same target language. French translations should maintain structural parity with their English counterparts.
Applied to files:
src/content/docs/en/guides/contributing/translations.mdx
🧬 Code graph analysis (1)
astro.config.mts (1)
src/starlight-sidebar/translate.ts (1)
getTranslations(16-31)
🪛 Gitleaks (8.30.0)
src/content/docs/en/start-here/getting-started.mdx
[high] 71-71: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 Hadolint (2.14.0)
Dockerfile
[error] 2-2: missing whitespace
(DL1000)
🪛 LanguageTool
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-31.mdx
[grammar] ~18-~18: Use a hyphen to join words.
Context: ...nificant changes, including a new Kysely based database layer, a revamped plugin ...
(QB_NEW_EN_HYPHEN)
[grammar] ~22-~22: Use a hyphen to join words.
Context: ...r more details. - Implemented new Kysely based database layer. - Removed support ...
(QB_NEW_EN_HYPHEN)
[grammar] ~73-~73: Use a hyphen to join words.
Context: ...w database connection for the new Kysely based database layer.** Update your `.en...
(QB_NEW_EN_HYPHEN)
[style] ~138-~138: Consider a more expressive alternative.
Context: ...tool you installed in previous step. To do this, continue to the next step, and us...
(DO_ACHIEVE)
src/content/docs/en/start-here/getting-started.mdx
[style] ~351-~351: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...d to find a plugin for the provider you want to use, or create your own plugin. <ReadM...
(REP_WANT_TO_VB)
[uncategorized] ~372-~372: The official name of this software platform is spelled with a capital “H”.
Context: ...tudiocms-plugins/studiocms-github/) | /studiocms_api/auth/github/callback | | [Discord](/en/package-cat...
(GITHUB)
src/content/docs/en/utils/kysely-and-sdk.mdx
[uncategorized] ~330-~330: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...ference management - Token Bucket - Rate limiting and token management ### Further Readi...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🔇 Additional comments (81)
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-18.mdx (1)
1-9: Confirmtopic: guidesandsidebar.hiddenare supported by your docs schema/build.
If these frontmatter keys aren’t recognized by Starlight/your content collection schema, they may be ignored or cause validation failures; worth double-checking the repo’s content config for allowed fields..github/workflows/ci-link-validator.yml (1)
6-8: Concurrency configuration improves CI efficiency.Adding the concurrency group prevents duplicate workflow runs when multiple commits are pushed in quick succession, and
cancel-in-progress: truewill automatically cancel stale runs. This aligns with GitHub Actions best practices and is consistent with the pattern used in other workflows in the repository.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-22.mdx (1)
5-9: Confirm the page-hiding intent and navigation path.
topic: guides+sidebar.hidden: truewill likely remove this from sidebar navigation; if this guide is still meant to be reachable, ensure there’s an index (e.g., upgrade hub) that links to it explicitly..github/workflows/ci-knip.yml (3)
9-11: ✓ Concurrency management improves workflow efficiency.Adding concurrency with
cancel-in-progress: trueprevents duplicate runs on the same branch, which reduces unnecessary resource consumption and avoids redundant linter executions. This is a best practice for CI workflows.
22-27: ✓ Clear job definition with appropriate guardrails.The restructured job includes:
- Explicit
namefor improved readability in the GitHub UI.NODE_OPTIONSenvironment variable to manage memory allocation—important for large linting scans.- Fork guard (
if: github.event.pull_request.head.repo.full_name == github.repository) to prevent execution on untrusted pull requests, which is a security best practice.These changes enhance both clarity and safety.
28-39: ✓ Clean step separation improves maintainability.The three-step structure (checkout → install → lint) provides clear separation of concerns:
- Checkout uses the custom token for authenticated access.
- Install step uses a consistent, reusable action from the
withstudiocms/automationsregistry.- Lint step is now explicit and easy to modify independently.
This organization aligns with workflow best practices and makes debugging simpler.
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-21.mdx (1)
1-9: Approved: Frontmatter changes align with the consistent pattern across version guides.The addition of
topic: guidesand the sidebarhidden: trueflag are valid and intentional. This keeps older beta upgrade guides accessible via direct links while removing them from sidebar navigation, which improves UX for users seeking current version information.Please confirm:
- Is this
hidden: truepattern intentionally applied across all beta version guides (beta-16 through beta-31) as described in the PR context?- Are you aware that Lunaria will mark this file as source-updated, triggering localization revalidation for translated versions?
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-24.mdx (1)
5-8: Verify that hiding older beta version guides doesn't break discoverability.The change from
order: 999991tohidden: trueremoves this upgrade guide from sidebar navigation. While the addition oftopic: guidesaligns with the documented pattern across other version guides, confirm that:
- Users can still access this page via direct links, search functionality, or alternative navigation (e.g., version switcher, changelog).
- No other parts of the documentation link directly to this page expecting it to be visible in the sidebar.
- The hiding of older beta versions is intentional deprecation rather than an unintended UX regression for users upgrading from intermediate versions.
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-17.mdx (1)
5-5: Metadata updates to frontmatter look good.The additions of
topic: guidesand the change tohidden: truefollow standard Astro/Starlight configuration patterns and are consistent with the broader pattern of updating version guide metadata across the PR (as noted in the AI summary context).However, verify that this visibility change aligns with your intended documentation structure:
- Hiding older version guides (beta.17 alongside beta-16 through beta-30) while releasing beta.31 is a common pattern to reduce navigation clutter and encourage users to follow current upgrade paths.
- Ensure that users who need to reference historical upgrade steps for beta.17 can still access this guide (e.g., via direct URL or search).
Please confirm:
- Is
hidden: truethe correct Starlight sidebar syntax for your documentation setup?- Is systematically hiding older beta version guides the intended outcome for this release?
Also applies to: 8-8
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-20.mdx (1)
1-9: Confirmtopic: guides+sidebar.hidden: trueare valid/desired in your Starlight setup (and won’t break nav grouping).
This will hide the page from sidebar navigation; make sure that’s intended for beta.20 and that thetopickey is consumed by your docs tooling as expected.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-23.mdx (1)
5-5: Front matter updates look good; verify sidebar visibility intent.The
topic: guidesmetadata addition aligns with documentation organization, and the changes are syntactically correct. However, settinghidden: trueremoves this upgrade guide from sidebar navigation—worth confirming this is intentional given that users upgrading from very old versions (beta.23) may need access to it.Please confirm that hiding older upgrade guides from the sidebar is the intended UX pattern for the beta.31 docs. If needed, consider whether a historical/archived guides section or a version-selector would better serve users upgrading from very old versions.
Also applies to: 8-8
src/starlightOverrides/Search.astro (1)
70-104: Verify the hardcoded API key and app ID are safe to expose.Lines 72-74 contain hardcoded Algolia credentials (
appId,indexName,apiKey). Confirm that these are public DocSearch credentials intended for client-side use and not sensitive secrets. If this is a public key for the StudioCMS documentation index, add an inline comment documenting that.For enhanced security and maintainability, consider migrating credentials to environment variables:
- appId: 'UAGEFSNZ02', - indexName: 'studiocms', - apiKey: '2db78946b26c84e691bbbd2e7db7e6a8', + appId: import.meta.env.PUBLIC_ALGOLIA_APP_ID, + indexName: import.meta.env.PUBLIC_ALGOLIA_INDEX_NAME, + apiKey: import.meta.env.PUBLIC_ALGOLIA_API_KEY,src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-19.mdx (1)
1-9: Frontmatter update looks consistent (topic + hidden sidebar entry).
topic: guides(Line 5) andsidebar.hidden: true(Line 8) match the intent of tagging upgrade notes while keeping older versions out of the sidebar clutter.ec.config.mjs (1)
15-15: LGTM! Valid TypeScript error codes added.The addition of error codes 7031 (implicit 'any' in binding element), 2554 (argument count mismatch), and 2375 (duplicate index signature) to the handbook errors configuration is correct and will allow these specific TypeScript errors to be properly handled in documentation code examples.
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-16.mdx (2)
11-12: The imports are correctly configured. The~/alias is defined intsconfig.json(lines 8-9:"~/*": ["src/*"]), and bothReadMore.astroandQuickUpdate.astrocomponents exist atsrc/components/. Astro automatically uses these path mappings for import resolution.
5-5: Inconsistency:sidebar.hiddenapplied only to beta-16 through beta-24, not beta-25 through beta-31.Both
topic: guides(fromstarlight-sidebar-topicsschema) andsidebar.hidden: true(standard Starlight property) are valid. However, the changes are applied inconsistently: beta-16 through beta-24 usesidebar.hidden: true, while beta-25 through beta-31 still usesidebar.orderwith descending values (999990, 999989, etc.). Clarify whether this partial application is intentional.src/components/PackageCatalog.astro (1)
32-60: LGTM! Hidden package filtering and empty state handling implemented correctly.The filtering logic correctly excludes hidden packages, and the conditional rendering provides a good user experience when no packages are available. The implementation safely destructures the
hiddenfield since it has a default value in the schema.src/pages/index.astro (1)
2-13: LGTM! StarlightPage wrapper applied consistently.The change properly wraps the redirect meta tag with StarlightPage and provides appropriate frontmatter metadata. This aligns with the pattern used across other pages in this PR.
src/pages/[...enRedirectSlug].astro (1)
3-26: LGTM! Redirect page properly migrated to StarlightPage pattern.The implementation correctly extracts page metadata from
getStaticPathsprops and uses it in the StarlightPage frontmatter. The redirect logic is preserved and the pattern is consistent with other pages in this PR.src/content.config.ts (1)
20-20: LGTM! Schema extension for hidden packages is well-designed.The
hiddenfield is properly defined with a sensible default (false), ensuring backward compatibility with existing package catalog entries while supporting the new filtering functionality.src/content/package-catalog/studiocms-web-vitals.json (1)
10-11: The schema file referenced in the catalog entries does not exist; thehiddenfield lacks validation but is consistently applied.The schema file at
../../../.astro/collections/package-catalog.schema.jsondoes not exist in the repository, and no schema validation infrastructure is present. Thehidden: truefield is being added to catalog entries without schema definition or validation.However, the consistency check passes: both
@studiocms/web-vitalsand@astrojs/web-vitalsentries have matching visibility configuration (publiclyUsable: falseandhidden: true), so the semantic intent—hiding deprecated or non-public packages from listings—is applied uniformly.Consider:
- Whether schema validation is actually enforced for these catalog files.
- If schema validation is intended, add the
hiddenfield definition to the schema.- Ensure downstream code that reads these catalog entries handles the
hiddenflag appropriately, since validation cannot catch inconsistencies.⛔ Skipped due to learnings
Learnt from: ArmandPhilippot Repo: withstudiocms/docs PR: 140 File: src/content/docs/fr/guides/upgrade/version-guides/0-1-0-beta-19.mdx:24-24 Timestamp: 2025-07-21T12:16:32.374Z Learning: In the withstudiocms/docs repository, documentation URLs in the package-catalog may maintain legacy path names for stability and consistency across language versions, even when the actual package names have been updated. Always verify that corresponding files exist before flagging URLs as broken.src/components/ModalScript.astro (1)
1-10: LGTM! Import path refactored and modal initializations expanded.The import has been updated to the client-specific
studiocms:ui/components/modal/clientmodule, and multiple modals are properly initialized with their corresponding triggers. The implementation is clean and follows a consistent pattern.src/components/ToasterScript.astro (1)
1-11: LGTM! Import path refactored to client-specific module.The import path has been updated to
studiocms:ui/components/toaster/client, a more specific subpath provided by the@studiocms/uiAstro integration. The toast function usage remains correct, and the import is used consistently throughout the codebase with no redundant imports elsewhere.src/components/ContributorList.astro (1)
15-15: LGTM! Flex-based layout improves responsiveness.The refactor from grid to flexbox with wrapping provides better responsive behavior for varying contributor group sizes. The flex-item sizing constraints (15rem min, 25rem max) ensure consistent presentation across viewports.
Also applies to: 27-50
src/util/contributors.config.ts (3)
7-7: LGTM! Type extension is clean.The optional
ignoredPathsfield appropriately extends theRepoListItemtype to support path-based filtering.
67-89: Configuration structure is correct.The addition of
ignoredPathsto excludepackages/@studiocms/devapps/from the plugins section while including the broaderpackages/@studiocms/path clearly separates devapps contributors from plugin contributors.
130-139: LGTM! New internal-packages category is well-defined.The addition of the internal-packages contributor group with the
packages/@withstudiocms/path provides a clear separation from other package categories.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-26.mdx (1)
1-9: Good metadata normalization; ensuretopicis supported by the docs frontmatter schema.
If the site validates frontmatter (Astro Content Layer / Starlight), confirmtopicis an allowed field and thatguidesmatches the expected enum/string values.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-25.mdx (1)
1-9: Consistent with other upgrade guides; just verify frontmatter schema acceptance.
Same note as elsewhere: make suretopicis declared/handled (andguidesis a valid value) to avoid build-time content validation errors.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-27.mdx (1)
1-9: Looks good; keep an eye on schema + nav grouping behavior.
Iftopicaffects sidebar grouping, double-check this page lands under the intended section (and doesn’t duplicate/relocate unexpectedly).src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-28.mdx (1)
1-9: LGTM; verifytopicdoesn’t conflict with existing categorization (e.g.,upgrade).
Since these are already under anupgrade/version-guidespath, ensure whatever consumestopicdoesn’t create a confusing double-category in UI.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-30.mdx (1)
1-9: Good metadata alignment; please confirm frontmatter validation passes.
Nothing else changed here—so any CI failure would likely be schema/collection validation around the new key.src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-29.mdx (1)
1-9: Consistent frontmatter update; just ensure schema acceptstopic.
If you have typed frontmatter/content collections, update the schema once (not per-file) to includetopic.src/content/docs/en/config-reference/index.mdx (1)
7-10: Sidebar “Updated” badge looks consistent with the broader docs sweep.src/content/docs/en/config-reference/features.mdx (2)
7-10: Sidebar “Updated” badge is consistent with the other refreshed pages.
361-380:preferredImageService: 'cloudinary-js'example is clearer thanundefined..vscode/settings.json (1)
2-16: cSpell additions are reasonable for the terminology used in this repo.src/content/docs/en/plugins/renderers.mdx (2)
7-10: Badge update is consistent with the rest of the “beta.31” doc refresh.
89-93: "Further Reading" is a good addition; the linked route is correctly configured. The referenced guide file exists atsrc/content/docs/en/guides/custom-frontend/rendering.mdx.src/content/docs/en/guides/contributing/translations.mdx (2)
7-10: Sidebar “Updated” badge is consistent with the docs refresh.
35-36: No action needed—both GitHub URLs are valid and resolve correctly.The documentation links to
packages/studiocms/src/virtuals/i18n/translations/directory anden.jsonfile are accurate and functional in the current main branch. Contributors following these links will not encounter 404 errors.src/content/docs/en/utils/template-lang.mdx (2)
1-14: Frontmatter + catalog integration wiring looks coherent (catalogEntrymatches catalog file).Please just confirm
type: integrationis a valid/expected frontmatter field for this site’s content schema.
67-148: Verify actual package implementation against documentation. The documented API shows aTemplateEngineclass with synchronousrender()andcompile()methods, but search results hint at aTemplatePlugininterface with different method signatures. Confirm the package exportsTemplateEngineas default export and verify all documented methods (render,compile,hasVariables,getVariables,setOptions) and options (strict,defaultValuewith stated defaults) match the actual implementation in the source repository.src/content/package-catalog/withstudiocms-template-lang.json (1)
1-9: Package-catalog entry is correctly configured. The documentation file exists at the linked route, and the catalogEntry ID in the MDX frontmatter (withstudiocms-template-lang) matches both the JSON filename and internal references. No issues detected.src/content/docs/en/plugins/extended.mdx (4)
88-88: LGTM!The minimum version update to
0.1.0-beta.31correctly reflects the new plugin API requirements for this release.
90-92: LGTM!The hook rename from
studiocms:astro:configtostudiocms:astro-configimproves consistency with the new naming convention using hyphens instead of nested colons.
93-132: LGTM!The refactored
studiocms:dashboardhook with focused signature({ setDashboard })improves API clarity by separating dashboard configuration concerns.
134-149: LGTM! Well-designed API separation.The new
studiocms:frontendandstudiocms:renderinghooks provide clear separation of concerns for navigation and page type configuration.src/content/docs/en/config-reference/locale.mdx (1)
68-88: LGTM!The new
i18nconfiguration section is well-documented with clear type information and a practical example showingdefaultLocaleusage.src/content/docs/en/how-it-works/sdk.mdx (2)
14-14: LGTM! Important architectural documentation update.The description correctly reflects the migration from Astro DB to the in-house Kysely database client, which is a significant architectural change in beta.31.
52-71: LGTM! Expanded SDK surface aligns with beta.31 features.The expanded SDK exports correctly reflect the new capabilities including authentication, caching, middleware, and plugin system utilities documented in the beta.31 release.
src/content/docs/en/start-here/environment-variables.mdx (2)
28-60: LGTM! Comprehensive multi-database documentation.The restructured database connection section properly documents all three supported database dialects (libSQL, MySQL, PostgreSQL) with clear examples. The new
CMS_*environment variable naming convention is breaking but well-documented.
77-90: LGTM! Helpful optional configuration.The new
STUDIOCMS_LOGLEVELdocumentation provides clear guidance on Effect-based logging configuration with appropriate default and well-documented level options.src/content/docs/en/utils/kysely-and-sdk.mdx (4)
19-33: LGTM! Clear introduction with appropriate warnings.The introduction effectively explains Kysely's role and sets proper expectations with a caution about the packages being primarily for internal use.
57-75: LGTM! Clear Effect-ts integration example.The basic client setup demonstrates the Effect-ts pattern and ConfigProvider usage effectively, providing a solid foundation for understanding the database client initialization.
79-254: LGTM! Excellent progressive examples.The three examples (withDecoder, withEncoder, withCodec) progressively demonstrate database patterns with helpful type annotations showing the inferred TypeScript types, making it easy to understand the benefits of each approach.
313-340: LGTM! Comprehensive SDK feature overview.The SDK package section provides a clear feature list with appropriate references to implementation details and usage documentation, avoiding duplication while providing sufficient context.
src/content/docs/en/guides/upgrade/version-guides/0-1-0-beta-31.mdx (2)
20-24: LGTM! Clear breaking changes documentation.The breaking changes section concisely identifies the major architectural changes with appropriate links to detailed documentation.
160-165: LGTM! Appropriate final safety reminders.The final notes section provides essential backup and testing reminders with helpful community support links.
astro.config.mts (4)
11-11: LGTM! Well-configured LLM documentation integration.The
starlight-llms-txtplugin is properly imported and configured with a clear description and focused custom set for getting started content, making the documentation more accessible to AI assistants.Also applies to: 164-173
20-27: LGTM! Simplified link validation configuration.The streamlined link validator configuration with stricter error handling (errorOnFallbackPages, errorOnInconsistentLocale) improves documentation quality checks while removing unnecessary exclusions.
121-132: LGTM! Proper production-only analytics.The conditional analytics loading ensures tracking only occurs in production, which is a best practice for development workflows.
199-203: LGTM! Logical navigation structure expansion.The new
utilsandcustom-frontendsections properly integrate with the navigation structure, using translations and autogeneration patterns consistent with existing sections.Also applies to: 241-245
package.json (2)
84-85: LGTM! The addition ofstarlight-llms-txtaligns with the new plugin usage inastro.config.mts. Version^0.6.0is the latest stable release and correctly specified.
24-35: pkg.pr.new URLs are intentional for pre-release documentation.The StudioCMS package dependencies use pkg.pr.new preview URLs because the documentation is configured in pre-release mode (
const pre = true;ingenerate-release-notes.ts). These URLs will naturally expire once the upstream PRs are merged, at which point they should be updated to stable versions as part of the release process. No action needed at this stage.src/content/docs/en/plugins/index.mdx (2)
6-9: LGTM: Documentation UI enhancements.The addition of UI badges (sidebar "Updated" badge and inline "Revised beta.31" badge) effectively highlights significant changes for users browsing the documentation.
Also applies to: 12-12, 23-23
26-61: Breaking API changes properly documented.The plugin API has undergone significant changes:
- Hook renamed:
studiocms:config:setup→studiocms:authwith simplified parameters- Hook renamed:
studiocms:astro:config→studiocms:astro-config- New hooks added:
studiocms:dashboard,studiocms:frontend,studiocms:rendering,studiocms:image-service,studiocms:sitemap- Minimum version bumped to
0.1.0-beta.31These breaking changes are appropriate for a beta release and are clearly documented with version badges and updated examples.
Also applies to: 97-97, 99-99
src/content/docs/en/guides/index.mdx (1)
18-20: LGTM: New documentation section added.The "Custom Frontend Guides" section is properly structured and links to the new rendering content page.
Dockerfile (1)
1-15: Multi-stage Docker build is well-structured.The Dockerfile follows best practices with a clear separation between build and runtime stages. The use of
nginx:alpinefor the runtime provides a lightweight production image.src/content/docs/en/guides/custom-frontend/rendering.mdx (1)
8-8: LGTM: Documentation enhanced with contextual links.The addition of the ReadMore component and updated Aside text with links to custom renderer plugin documentation improves discoverability and provides clear next steps for users.
Also applies to: 15-15, 46-50
src/content/docs/en/how-it-works/index.mdx (1)
6-9: LGTM: Documentation updated to reflect database abstraction.The removal of specific "Astro DB" references aligns with the migration to Kysely as documented in other files, making the documentation more accurate and database-agnostic.
Also applies to: 14-14, 18-18
src/content/docs/en/start-here/why-studioCMS.mdx (1)
4-4: LGTM: Key features updated to reflect Kysely integration.The documentation accurately reflects the shift from Astro DB to a flexible Kysely-based solution, highlighting support for multiple database dialects and extensibility.
Also applies to: 7-9, 23-23
src/starlightOverrides/AdBanner.astro (1)
1-119: LGTM: Well-structured ad banner component.The AdBanner component follows best practices:
- Semantic HTML with proper ARIA labeling (
aria-labelledby)- Responsive design using modern container queries
- Accessibility-friendly with proper heading hierarchy
- Excludes ad content from search indexing via
data-algolia-exclude- Uses Starlight's LinkButton for consistent styling
.github/workflows/ci-docker-pr.yml (1)
64-64: Clarify deployment step placement.The comment states these steps are a test and would be moved to the main branch workflow later. However, checking the main workflow (ci-docker-main.yml), similar deployment steps already exist there. Are these PR-scoped deployment steps intentional, or should they be removed from the PR workflow?
src/content/docs/en/start-here/configuration.mdx (1)
1-65: LGTM! Documentation updates are clear and consistent.The removal of
db()integration and addition of the Further Reading section align well with the broader migration to beta.31. The badge and content updates effectively communicate the changes to users.src/content/docs/en/package-catalog/studiocms-plugins/studiocms-devapps.mdx (1)
1-111: LGTM! Documentation properly updated for beta.31.The replacement of placeholder comments with actual
<Steps>components improves the documentation structure. The migration fromdb()tostudiocms()is consistent throughout, and the removal of the LibSQL Viewer tool section aligns with the PR's broader changes.src/starlightOverrides/PageSidebar.astro (1)
2-5: LGTM! Standard pattern for Starlight virtual imports.Using
@ts-expect-errorfor virtual imports from Starlight is the expected pattern when type definitions aren't available at compile time.src/content/docs/en/how-it-works/cli.mdx (1)
1-315: LGTM! Comprehensive CLI documentation updates.The migration from tab-based command examples to
PackageManagerscomponents improves consistency. The newdebugandmigratecommand documentation, along with the migrator section, provides clear guidance for users.src/content/docs/en/start-here/getting-started.mdx (3)
23-27: LGTM! Effective warning for breaking changes.The caution notice appropriately alerts users to the significant changes in beta.31 and directs them to the upgrade guide. This helps prevent confusion for users following older versions of this guide.
54-123: LGTM! Clear database setup organization.The tab-based organization for different database types (Turso, libSQL, MySQL, PostgreSQL) makes it easy for users to find relevant setup instructions. The environment variable renaming from
ASTRO_DB_*toCMS_*is consistent throughout.
268-297: LGTM! Clear dialect configuration guidance.The new database dialect configuration section provides clear instructions for users of MySQL and PostgreSQL. The inclusion of required package installation commands for each dialect is helpful.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
src/util/getContributors.ts (1)
130-135: Filtering logic remains unreliable and won't work as intended.This filtering approach was previously flagged as broken. The current implementation still filters commits by checking if the commit message contains the ignored path, which is fundamentally unreliable.
Why this fails:
- Commit messages rarely contain file paths like
packages/@studiocms/devapps/- The GitHub API
?path=parameter already filters commits that touched files under that path, but it cannot distinguish between parent and child directories (e.g.,packages/@studiocms/plugin/vs.packages/@studiocms/devapps/)- A commit touching
packages/@studiocms/devapps/feature.tswith message "Add new feature" will not be filtered outCorrect approach:
Check the files changed in each commit, not the commit message. This requires fetching commit details per commit to inspectcommit.filesand determine if anyfile.filenamestarts with anyignoredPath.The previous review comment on these lines provides a detailed correct implementation. Please refer to that comment for the full solution.
🧹 Nitpick comments (1)
.github/workflows/ci-docker-pr.yml (1)
59-62: Verification step is informational only.The "Verify pushed image" step (lines 59-62) only echoes the expected tags but doesn't validate that the image was actually pushed to GHCR. Consider adding a real verification step using
docker pullor registry API lookup if push validation is important.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.github/workflows/ci-docker-pr.yml(1 hunks)Dockerfile(1 hunks)nginx.conf(1 hunks)scripts/lib/changelogs.ts(1 hunks)src/util/getContributors.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- nginx.conf
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: ArmandPhilippot
Repo: withstudiocms/docs PR: 149
File: src/content/docs/fr/guides/upgrade/version-guides/0-1-0-beta-21.mdx:13-15
Timestamp: 2025-07-24T11:57:15.225Z
Learning: In the withstudiocms/docs repository, when reviewing French translation files, maintain consistency with the English version even if it means keeping unused imports. Structural parity between language versions is prioritized over removing unused code.
Learnt from: ArmandPhilippot
Repo: withstudiocms/docs PR: 149
File: src/content/docs/fr/guides/upgrade/version-guides/0-1-0-beta-20.mdx:18-18
Timestamp: 2025-07-24T12:00:35.014Z
Learning: In the withstudiocms/docs repository, while translations should maintain structural parity with English versions, improving readability during translation is acceptable when the original text has clear redundancy or readability issues that would also impact the translation quality. The maintainer ArmandPhilippot confirmed this approach is reasonable when the technical meaning is preserved.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Run Starlight Link Check
- GitHub Check: build-and-push
🔇 Additional comments (6)
Dockerfile (2)
2-2: Previous syntax error appears addressed.The RUN command now properly includes a shell command (
export PUBLIC_GITHUB_TOKEN...) after the--mountdirective, fixing the earlier critical issue. The secret is correctly consumed from the mounted path.
4-11: Build stage is properly configured.Corepack installation, pnpm setup, and frozen lockfile usage are all correct for reproducible builds.
.github/workflows/ci-docker-pr.yml (3)
1-14: Workflow trigger and permissions are correctly configured.The trigger on
pull_requesttomainis appropriate for PR validation, permissions are minimal (contents:read, packages:write), and concurrency control prevents duplicate runs.
20-43: Build prerequisites are properly configured.Checkout, QEMU multi-arch setup, Buildx, pnpm store caching, and GHCR authentication are all correct and follow best practices.
44-57: Platform specification mismatch with multi-arch setup.Line 23-27 set up QEMU and Buildx for multi-architecture builds, but line 49 specifies only
linux/amd64. This is either an intentional optimization (to reduce PR build time) or an oversight. If multi-platform support is desired for PRs, specify additional platforms (e.g.,linux/amd64,linux/arm64).Verify that the single-platform approach aligns with project CI strategy by checking the main workflow configuration in
.github/workflows/ci-docker-main.ymlto see if it builds multiple platforms.scripts/lib/changelogs.ts (1)
23-37: Bearer token authentication is correctly implemented; however, there is a token exposure issue in a different file.The code in
scripts/lib/changelogs.tscorrectly usesBearertoken authentication and is not vulnerable to client-side exposure. Thescripts/directory contains Node.js build scripts whereprocess.env.PUBLIC_GITHUB_TOKENis simply a normal environment variable name—thePUBLIC_prefix has no special meaning in Node.js and does not expose the token to client code.However, the actual security vulnerability exists in
src/util/getContributors.ts:49, which usesimport.meta.env.PUBLIC_GITHUB_TOKEN. In Astro, thePUBLIC_prefix makes environment variables available to client-side code. While this function is currently only used in.astrocomponents (server-side), usingPUBLIC_GITHUB_TOKENhere violates the principle of least privilege and could expose the token if the function is ever imported into client-side JavaScript.Update
src/util/getContributors.tsto use a server-only environment variable:- const token = import.meta.env.PUBLIC_GITHUB_TOKEN; + const token = import.meta.env.GITHUB_TOKEN;Ensure:
- The variable is set as
GITHUB_TOKEN(notPUBLIC_GITHUB_TOKEN) in your CI/CD and deployment environment- The token is stored as a secret in GitHub Actions and other services
- If previously exposed, rotate the token immediately
Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/util/getContributors.ts (1)
50-50: Use a private environment variable instead of PUBLIC_GITHUB_TOKEN.The
PUBLIC_GITHUB_TOKENenvironment variable is used as a secret API token, but in Astro, thePUBLIC_prefix is reserved for non-sensitive values that are intentionally exposed to the browser. Secrets and API credentials should use environment variables without thePUBLIC_prefix.While this code runs server-side only (in Astro component frontmatter), using
PUBLIC_for a secret token is semantically incorrect and creates a dangerous pattern. Change to:-const token = import.meta.env.PUBLIC_GITHUB_TOKEN; +const token = import.meta.env.GITHUB_TOKEN;Also applies to: 89-89
🧹 Nitpick comments (3)
src/util/getContributors.ts (3)
17-17: Unused field added to interface.The
shafield is added to theCommitinterface but is never used in the current implementation. Based on the past review comment, this field (along with the newsingleFetchfunction) appears to be preparation for implementing proper commit filtering by fetching individual commit details to inspect changed files. However, the actual filtering logic hasn't been implemented yet.If this field is not needed for the current implementation, consider removing it until the full filtering solution is ready. Otherwise, track this as a TODO to complete the implementation suggested in the previous review.
86-116: Unused function:singleFetchis never called.The
singleFetchfunction is defined but not invoked anywhere in the codebase. This appears to be preparation for implementing the fix suggested in the previous review (fetching individual commit details to properly filter by changed files), but the actual implementation is incomplete.Options:
- If this is work-in-progress, add a TODO comment explaining the intended use
- If not needed yet, remove the function to reduce maintenance burden
- Complete the implementation by using this function to fetch commit details as suggested in the previous review
158-159: Consider structured logging for production.The added
console.logstatement is helpful for debugging, but for production environments, consider using a structured logging approach that allows for log levels (debug, info, warn, error) and easier filtering.Example:
-console.log(`Getting contributors for repo: ${repo}, paths: ${paths.join(', ')}`); +console.debug(`[getContributors] Fetching contributors for repo: ${repo}, paths: ${paths.join(', ')}`);Or use a logging library if the project has one configured. The current implementation is acceptable for debugging purposes.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/util/contributors.config.ts(4 hunks)src/util/getContributors.ts(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/util/contributors.config.ts
🧰 Additional context used
🧬 Code graph analysis (1)
src/util/getContributors.ts (1)
src/util-server.ts (1)
cachedFetch(15-49)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Run Starlight Link Check
- GitHub Check: build-and-push
5 participants
Description
TODO Before merge:
update pkg.pr.new references to actual packages once released
Closes #
What does this PR change? Give us a brief description.
Summary by CodeRabbit
New Features
Documentation
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.