Update package dependencies and enhance documentation workflows#3
Update package dependencies and enhance documentation workflows#3BurnedChris wants to merge 8 commits intomainfrom
Conversation
- Added new dependencies for remark-related packages in package.json to improve documentation formatting and linting. - Updated the GitHub Actions workflow for bundle analysis to use a maintained action, ensuring better compatibility and performance. - Refined documentation files by standardizing bullet points and improving readability across various sections. - Removed outdated bundle analysis action files to streamline the repository and reduce maintenance overhead.
WalkthroughRemoves two in-repo GitHub Actions (bundle-analysis-action and c15t-github-action), deletes many related TypeScript modules and tests, switches bundle analysis to a marketplace action, adds reusable and PR-triggered docs deploy workflows, and applies widespread Markdown list-formatting and docs tooling changes. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Potential focus areas:
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
- Added a step to format documentation using pnpm fmt:docs in the autofix workflow. - Updated the type checking step in the CI workflow to use the more descriptive command 'typecheck' instead of 'check-types'.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (82)
.github/workflows/autofix.yml(1 hunks).github/workflows/bundle-analysis.yml(1 hunks).github/workflows/ci.yml(1 hunks).github/workflows/deploy-docs-main.yml(3 hunks)docs/architecture.mdx(7 hunks)docs/frameworks/hono/advanced.mdx(1 hunks)docs/frameworks/hono/configuration.mdx(1 hunks)docs/frameworks/hono/deployment.mdx(1 hunks)docs/frameworks/hono/orchestration.mdx(2 hunks)docs/frameworks/hono/quickstart.mdx(2 hunks)docs/frameworks/hono/writing-runners.mdx(1 hunks)docs/frameworks/http/advanced.mdx(1 hunks)docs/frameworks/http/deployment.mdx(1 hunks)docs/frameworks/http/orchestration.mdx(2 hunks)docs/frameworks/http/quickstart.mdx(2 hunks)docs/frameworks/http/writing-runners.mdx(1 hunks)docs/frameworks/index.mdx(0 hunks)docs/frameworks/nitro/advanced.mdx(1 hunks)docs/frameworks/nitro/configuration.mdx(2 hunks)docs/frameworks/nitro/deployment.mdx(2 hunks)docs/frameworks/nitro/orchestration.mdx(2 hunks)docs/frameworks/nitro/quickstart.mdx(1 hunks)docs/frameworks/nitro/writing-runners.mdx(1 hunks)docs/frameworks/shared/advanced.mdx(1 hunks)docs/frameworks/shared/orchestration.mdx(1 hunks)docs/frameworks/shared/writing-runners.mdx(1 hunks)docs/getting-started.mdx(3 hunks)docs/introduction.mdx(1 hunks)docs/oss/contributing.mdx(5 hunks)docs/oss/license.mdx(0 hunks)docs/reference/api.mdx(16 hunks)docs/reference/cli.mdx(4 hunks)docs/reference/index.mdx(1 hunks)internals/bundle-analysis-action/README.md(0 hunks)internals/bundle-analysis-action/action.yml(0 hunks)internals/bundle-analysis-action/package.json(0 hunks)internals/bundle-analysis-action/src/analyze/bundle-analysis.test.ts(0 hunks)internals/bundle-analysis-action/src/analyze/bundle-analysis.ts(0 hunks)internals/bundle-analysis-action/src/config/inputs.ts(0 hunks)internals/bundle-analysis-action/src/github/pr-comment.test.ts(0 hunks)internals/bundle-analysis-action/src/github/pr-comment.ts(0 hunks)internals/bundle-analysis-action/src/main.test.ts(0 hunks)internals/bundle-analysis-action/src/main.ts(0 hunks)internals/bundle-analysis-action/tsconfig.json(0 hunks)internals/bundle-analysis-action/vitest.config.ts(0 hunks)internals/c15t-github-action/README.md(0 hunks)internals/c15t-github-action/__tests__/ascii-art.test.ts(0 hunks)internals/c15t-github-action/__tests__/assets/result(0 hunks)internals/c15t-github-action/__tests__/assets/result2(0 hunks)internals/c15t-github-action/__tests__/changes.test.ts(0 hunks)internals/c15t-github-action/__tests__/comment.test.ts(0 hunks)internals/c15t-github-action/__tests__/comments.test.ts(0 hunks)internals/c15t-github-action/__tests__/config.test.ts(0 hunks)internals/c15t-github-action/__tests__/deployment.test.ts(0 hunks)internals/c15t-github-action/__tests__/errors.test.ts(0 hunks)internals/c15t-github-action/__tests__/improvements.test.ts(0 hunks)internals/c15t-github-action/__tests__/logger.test.ts(0 hunks)internals/c15t-github-action/__tests__/push-comment.test.ts(0 hunks)internals/c15t-github-action/__tests__/render-comment.test.ts(0 hunks)internals/c15t-github-action/__tests__/validate.test.ts(0 hunks)internals/c15t-github-action/__tests__/vercel-client.test.ts(0 hunks)internals/c15t-github-action/action.yml(0 hunks)internals/c15t-github-action/package.json(0 hunks)internals/c15t-github-action/src/config/inputs.ts(0 hunks)internals/c15t-github-action/src/deploy/vercel-client.ts(0 hunks)internals/c15t-github-action/src/github/pr-comment.ts(0 hunks)internals/c15t-github-action/src/main.ts(0 hunks)internals/c15t-github-action/src/steps/ascii-art.ts(0 hunks)internals/c15t-github-action/src/steps/changes.ts(0 hunks)internals/c15t-github-action/src/steps/comments.ts(0 hunks)internals/c15t-github-action/src/steps/deployment.ts(0 hunks)internals/c15t-github-action/src/steps/first-commit.ts(0 hunks)internals/c15t-github-action/src/steps/github-app-auth.ts(0 hunks)internals/c15t-github-action/src/steps/push-comment.ts(0 hunks)internals/c15t-github-action/src/steps/render-comment.ts(0 hunks)internals/c15t-github-action/src/steps/setup-docs.ts(0 hunks)internals/c15t-github-action/src/steps/template-tracking.ts(0 hunks)internals/c15t-github-action/src/utils/errors.ts(0 hunks)internals/c15t-github-action/src/utils/logger.ts(0 hunks)internals/c15t-github-action/tsconfig.json(0 hunks)internals/c15t-github-action/vitest.config.ts(0 hunks)package.json(2 hunks)
💤 Files with no reviewable changes (50)
- internals/c15t-github-action/tests/validate.test.ts
- internals/c15t-github-action/tests/comments.test.ts
- internals/c15t-github-action/src/steps/push-comment.ts
- internals/c15t-github-action/package.json
- docs/oss/license.mdx
- internals/c15t-github-action/src/steps/github-app-auth.ts
- internals/c15t-github-action/src/utils/errors.ts
- internals/c15t-github-action/src/steps/ascii-art.ts
- internals/c15t-github-action/tests/improvements.test.ts
- internals/bundle-analysis-action/action.yml
- internals/c15t-github-action/tests/push-comment.test.ts
- internals/c15t-github-action/tests/changes.test.ts
- internals/c15t-github-action/tests/deployment.test.ts
- internals/c15t-github-action/tests/comment.test.ts
- internals/bundle-analysis-action/src/github/pr-comment.test.ts
- internals/bundle-analysis-action/README.md
- internals/c15t-github-action/src/steps/setup-docs.ts
- internals/bundle-analysis-action/src/main.test.ts
- internals/c15t-github-action/tests/errors.test.ts
- internals/c15t-github-action/action.yml
- internals/c15t-github-action/tests/vercel-client.test.ts
- internals/c15t-github-action/tsconfig.json
- internals/c15t-github-action/src/steps/comments.ts
- internals/c15t-github-action/README.md
- internals/c15t-github-action/vitest.config.ts
- internals/bundle-analysis-action/src/config/inputs.ts
- internals/c15t-github-action/src/steps/deployment.ts
- internals/c15t-github-action/src/steps/template-tracking.ts
- internals/c15t-github-action/src/main.ts
- internals/bundle-analysis-action/src/analyze/bundle-analysis.ts
- internals/bundle-analysis-action/src/github/pr-comment.ts
- internals/c15t-github-action/src/steps/changes.ts
- internals/bundle-analysis-action/tsconfig.json
- internals/c15t-github-action/src/steps/render-comment.ts
- internals/c15t-github-action/tests/config.test.ts
- internals/c15t-github-action/tests/assets/result
- internals/c15t-github-action/tests/assets/result2
- internals/c15t-github-action/tests/logger.test.ts
- internals/c15t-github-action/src/github/pr-comment.ts
- internals/c15t-github-action/src/config/inputs.ts
- internals/bundle-analysis-action/src/main.ts
- internals/bundle-analysis-action/package.json
- internals/c15t-github-action/tests/render-comment.test.ts
- internals/c15t-github-action/src/steps/first-commit.ts
- internals/bundle-analysis-action/vitest.config.ts
- internals/c15t-github-action/tests/ascii-art.test.ts
- internals/c15t-github-action/src/utils/logger.ts
- docs/frameworks/index.mdx
- internals/bundle-analysis-action/src/analyze/bundle-analysis.test.ts
- internals/c15t-github-action/src/deploy/vercel-client.ts
🧰 Additional context used
🪛 YAMLlint (1.37.1)
.github/workflows/deploy-docs-main.yml
[error] 83-83: too many blank lines (1 > 0)
(empty-lines)
⏰ 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). (3)
- GitHub Check: 🧹 Lint & Type Check
- GitHub Check: 🏗️ Build Packages
- GitHub Check: 📦 Bundle Size Analysis
🔇 Additional comments (42)
docs/frameworks/shared/advanced.mdx (3)
49-91: Performance section looks good.Code examples are syntactically correct and the explanations align with modern best practices (schema pre-extraction, parallel execution, browser reuse, lazy loading).
128-145: Unit testing example is well-structured.The vitest example correctly demonstrates runner testing with a mock context and assertion. The example is clear and follows testing best practices.
173-189: Custom Browser Options example is sound.The code correctly demonstrates creating a custom browser context with viewport and userAgent options. Syntax and pattern are correct.
package.json (2)
10-10: fmt:docs script syntax looks correct.The script runs remark on all markdown files and rewrites them with --output. Plugin order (MDX/frontmatter parsers before lint presets) is appropriate. Verify that the
./docsdirectory path is correct relative to package.json location.
19-23: Remark dependency versions are current and compatible with the project.remark-preset-lint-recommended@7.0.1 and remark-cli@12.0.1 are both latest releases. remark-cli@^12 targets Node.js 16+, which is compatible with the project's Node 18+ requirement. No
.remarkrcorremark.config.jsfiles exist in the repository; CLI flags in thefmt:docsscript are the sole configuration method.docs/frameworks/hono/configuration.mdx (1)
52-53: Documentation formatting standardization looks good.Bullet point style updated to align with remark-preset-lint-consistent standards. No content changes.
docs/frameworks/hono/orchestration.mdx (2)
85-89: API Endpoints bullet points standardized to asterisk format.Formatting change aligns with the new remark-based documentation linting. No functional impact.
101-102: See Also links updated to consistent bullet format.Aligns with the broader documentation standardization introduced in this PR.
docs/reference/cli.mdx (4)
44-44: Blank line after code section header improves readability.Good formatting practice for visual clarity between description and code blocks.
118-119: Runner Discovery list standardized to asterisk bullets.Consistent with remark-preset-lint-consistent formatting.
195-197: Exit Codes list converted to consistent bullet format.No functional changes; formatting only.
317-319: See Also references updated to asterisk bullets.Aligns with documentation standardization across the repository.
docs/frameworks/hono/quickstart.mdx (2)
36-40: Module capabilities list formatting standardized with blank line separation.Improved readability with proper spacing before bullet list. Formatting aligns with remark standards.
176-178: Next Steps references standardized to asterisk bullets.Consistent documentation formatting change across the repository.
.github/workflows/autofix.yml (1)
43-44: New documentation formatting step is properly positioned in autofix workflow.The "📚 Format Documentation" step is correctly placed after code formatting and before package.json formatting, following a logical sequence for CI autofix operations.
.github/workflows/ci.yml (1)
38-39: Thetypechecktask is properly configured and no action is needed.The task is defined in
turbo.jsonwith"dependsOn": ["^build"], and all packages have correspondingtypecheckscripts usingtsc --noEmit. The change fromcheck-typestotypecheckin line 39 is correct and aligns with the workspace configuration..github/workflows/bundle-analysis.yml (1)
89-89: Theheaderinput parameter is valid and supported by the external action.The parameter exists in the bundle-analysis-action's
action.ymlwith the default value"bundle-analysis"and is optional (not required). No changes needed.docs/frameworks/hono/writing-runners.mdx (1)
37-45: ✓ Documentation formatting standardized.Bullet point conversion from dashes to asterisks improves consistency across the documentation suite.
docs/frameworks/http/writing-runners.mdx (1)
37-44: ✓ Documentation formatting standardized.Bullet formatting aligns with project-wide documentation improvements.
docs/architecture.mdx (1)
18-390: ✓ Documentation formatting enhanced for readability.Consistent conversion to asterisk bullets and improved indentation makes the architecture documentation clearer and more maintainable. The checkbox notation in the "Future Considerations" section appropriately uses Markdown task list syntax.
docs/frameworks/shared/writing-runners.mdx (1)
17-334: ✓ Documentation substantially improved with better organization and comprehensive examples.The restructuring with
<section>tags enables better navigation, semantic HTML, and cross-document imports. Expanded code examples and best practices make this shared documentation more valuable for framework-specific guides that import from it.docs/oss/contributing.mdx (1)
13-15: ✓ Contributing guide formatting standardized.Bullet point conversion from dashes to asterisks improves visual consistency throughout the document.
Also applies to: 92-102, 114-117, 145-148, 306-315, 323-325
.github/workflows/deploy-docs-main.yml (2)
1-2: ✓ Workflow naming updated to reflect Main deployment target.Clear and descriptive workflow name change.
42-82: Verify external action compatibility before merging.The replacement of the local action (
./internals/c15t-github-action) with the external action (consentdotio/github-actions/docs-preview-action@main) is a significant infrastructure change.The
fmt:docsscript exists inpackage.jsonand is properly configured with all required remark dependencies. However, manual verification is needed:
- Confirm the external action
consentdotio/github-actions/docs-preview-action@mainis accessible and production-ready- Validate that all input keys (
docs_template_repo,comment_marker_prefix, and others) are supported by the external action- Verify the action's stability and recent usage in other workflows if available
docs/frameworks/shared/orchestration.mdx (1)
17-334: ✓ Orchestration documentation significantly enhanced with practical examples.The expansion from basic setup to comprehensive usage guide including:
- New Run Modes section clarifying remote vs. local execution
- Detailed curl examples with realistic JSON payloads
- Concurrency and timeout configuration guidance
- Production-ready best practices with TypeScript examples
This makes the orchestration guide substantially more useful for both simple and advanced use cases. The
<section>tags enable framework-specific docs to import relevant sections.docs/frameworks/http/orchestration.mdx (1)
62-79: ✓ Documentation formatting standardized.Bullet point conversion from dashes to asterisks improves consistency. The document correctly imports the expanded shared orchestration sections via
<import>tags.docs/frameworks/http/quickstart.mdx (1)
163-166: Formatting standardization approved.The bullet list conversions (dash to asterisk) improve consistency and align with Markdown conventions. All links and content remain intact.
Also applies to: 219-221
docs/frameworks/nitro/deployment.mdx (1)
36-37: Formatting standardization approved.Bullet list conversions to asterisks improve documentation consistency. The blank line added before the Environment Variables section enhances readability.
Also applies to: 163-164
docs/frameworks/hono/deployment.mdx (1)
97-98: Formatting standardization approved.Next Steps bullets standardized to asterisks for consistency across documentation.
docs/frameworks/hono/advanced.mdx (1)
29-31: Formatting standardization approved.See Also section properly formatted as a bulleted list with asterisks, improving visual structure and readability.
docs/frameworks/http/advanced.mdx (1)
29-31: Formatting standardization approved.See Also section properly formatted as a bulleted list, maintaining consistency across framework documentation.
docs/frameworks/nitro/advanced.mdx (1)
29-31: Formatting standardization approved.See Also section standardized to asterisk bullets with appropriate spacing. Consistent with framework documentation guidelines.
docs/reference/index.mdx (1)
11-12: Formatting standardization approved.Reference index list standardized to asterisk bullets with improved visual compactness. Links remain intact and functional.
docs/frameworks/nitro/writing-runners.mdx (2)
37-39: Formatting standardization approved.Nitro-Specific Notes and See Also sections properly formatted with asterisk bullets. All content and links preserved.
Also applies to: 43-45
37-45: Remark configuration is committed inline within package.json, not as a separate configuration file.The verification confirms:
- The
fmt:docsscript exists with proper remark presets (remark-preset-lint-recommended,remark-preset-lint-consistent) and plugins (remark-mdx,remark-frontmatter) configured as CLI flags inpackage.json- All remark dependencies are committed (
remark-cli@^12.0.1,remark-frontmatter@^5.0.0,remark-mdx@^3.1.0,remark-preset-lint-recommended@^7.0.1,remark-preset-lint-consistent@^6.0.1)- No unconverted markdown dash bullets found; remaining dashes in deployment and CLI documentation files are legitimate YAML/GitHub Actions code examples
- All 30 documentation files in
/docsare within the scope of thefmt:docsscript (targets./docs --ext mdx)The remark configuration is embedded in
package.jsonrather than a separate.remarkrcfile—this is a valid, version-controlled approach and consistent with the package's tooling setup.docs/frameworks/nitro/orchestration.mdx (1)
79-83: Bullet formatting standardized correctly.The API Endpoints and See Also sections have been properly converted from dash-prefixed markers to asterisk bullets, maintaining consistent Markdown formatting throughout the document.
Also applies to: 95-96
docs/introduction.mdx (1)
11-15: Consistent bullet formatting throughout.All six sections with bullet lists have been uniformly converted to asterisk-prefixed markers, improving readability and following Markdown best practices.
Also applies to: 19-23, 31-35, 41-44, 50-54, 60-63
docs/frameworks/http/deployment.mdx (1)
132-132: Next Steps bullet properly formatted.The quickstart reference has been correctly formatted as a bullet item while preserving the link syntax.
docs/frameworks/nitro/configuration.mdx (1)
66-69: Comprehensive bullet formatting updates with preserved links.All four sections (Build Configuration, Development Mode, Production Mode, and Next Steps) have been properly converted to asterisk bullets, with all internal documentation links correctly preserved.
Also applies to: 83-86, 91-94, 96-99
docs/frameworks/nitro/quickstart.mdx (1)
124-127: Bullet points and links standardized.The API Endpoints and Next Steps sections have been properly formatted with consistent asterisk bullets, with all documentation links intact.
Also applies to: 131-133
docs/getting-started.mdx (1)
81-87: Appropriate bullet formatting with proper preservation of numbered steps.The Key Points and Next Steps sections have been converted to asterisk bullets. Importantly, the numbered steps in "Running Locally" section (lines 99-104) were correctly preserved as numbered lists rather than being converted to bullets, demonstrating proper formatting judgment.
Also applies to: 274-277
docs/reference/api.mdx (1)
21-23: Comprehensive bullet formatting with proper handling of special characters.All type definitions and API sections have been consistently converted to asterisk bullets. The escaped braces in endpoint paths (lines 304, 322:
\{runId}) are properly formatted to prevent unintended template variable interpretation in MDX.Also applies to: 60-63, 80-85, 113-117, 159-161, 431-437, 477-480, 530-533
| // Exponential backoff | ||
| await new Promise(resolve => | ||
| setTimeout(resolve, Math.pow(2, attempt) * 1000) | ||
| ); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Exponential backoff implementation looks good; consider adding optional enhancements.
The exponential backoff delay is correctly computed with Math.pow(2, attempt) * 1000, yielding 2s → 4s progression. This is a solid, valid pattern.
For production robustness, consider these optional enhancements:
- Jitter: Add randomness to prevent thundering herd (e.g.,
+ Math.random() * 1000). - Max backoff cap: Limit delay to prevent excessive waits (e.g., cap at 32 seconds).
- Initial delay: Some prefer starting with a smaller delay (e.g., 100ms) rather than 2s.
If you'd like to enhance this, here's a more robust variant:
// Exponential backoff with jitter and cap
const baseDelay = 1000;
const maxDelay = 32000;
const delay = Math.min(
Math.pow(2, attempt - 1) * baseDelay + Math.random() * baseDelay,
maxDelay
);
await new Promise(resolve => setTimeout(resolve, delay));This starts at 1s for the first retry, adds randomness, and caps at 32s.
🤖 Prompt for AI Agents
In docs/frameworks/shared/advanced.mdx around lines 113 to 116, replace the
simple exponential backoff (Math.pow(2, attempt) * 1000) with a more robust
variant: introduce a baseDelay (e.g., 1000ms), a maxDelay cap (e.g., 32000ms),
compute delay as Math.min(Math.pow(2, attempt - 1) * baseDelay + Math.random() *
baseDelay, maxDelay) to add jitter, start lower on the first retry, and prevent
unbounded waits, then await the timeout using that computed delay.
…n deployment - Introduced a new workflow for bundle size analysis, triggered on pull requests and pushes to main and canary branches, ensuring better visibility of bundle size changes. - Added a unified documentation deployment workflow that supports PR previews, production, and staging deployments, enhancing the deployment process with improved alias handling and caching. - Removed the outdated documentation deployment workflow to streamline the repository.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
.github/workflows/analysis-bundle.yml(1 hunks).github/workflows/ci-autofix.yml(1 hunks).github/workflows/ci-main.yml(1 hunks).github/workflows/deploy-docs-main.yml(0 hunks).github/workflows/deploy-docs.yml(1 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/deploy-docs-main.yml
⏰ 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). (3)
- GitHub Check: 🧹 Lint & Type Check
- GitHub Check: 🏗️ Build Packages
- GitHub Check: 📦 Bundle Size Analysis
🔇 Additional comments (4)
.github/workflows/deploy-docs.yml (2)
79-122: Pin thedocs-preview-actionto a stable version, verify all required secrets are configured, and validate action inputs.Three issues require attention:
Action version pinning: Like the bundle-analysis-action, this uses
@main(line 81). Pin it to a specific commit SHA or release tag for reproducibility and to prevent accidental breaking changes.Secret validation: Ensure all required secrets are configured in the repository:
CONSENT_APP_IDandCONSENT_APP_PRIVATE_KEY(GitHub App credentials)VERCEL_TOKEN,VERCEL_PROJECT_ID,VERCEL_ORG_ID(Vercel integration)CONSENT_GIT_TOKEN(Git access)If any of these are missing, the deployment will fail at runtime.
Action input validation: Verify that
consentdotio/github-actions/docs-preview-actionaccepts all the inputs provided (lines 82–122), particularly:
github_app_installation_id(hardcoded value81013186on line 87)- The various conditional input assignments (e.g.,
deploy_on_pr_base_branches,assign_alias_on_branch)- The
change_globsmulti-line glob patterns#!/bin/bash # Verify the action definition and required secrets echo "=== Fetching docs-preview-action definition ===" curl -s https://raw.githubusercontent.com/consentdotio/github-actions/main/docs-preview-action/action.yml 2>/dev/null | head -100 echo "" echo "=== Checking repository secrets (if accessible) ===" gh api repos/consentdotio/runners/secrets --jq '.[].name' 2>/dev/null | grep -E 'CONSENT|VERCEL' || echo "Could not fetch secrets or none configured"
58-62: The checkoutreflogic for pull_request events is correct as written.An empty
refstring inactions/checkout@v4for pull_request events defaults to the auto-created merge commit (refs/pull/:prNumber/merge), not the base branch. This is the intended GitHub Actions behavior and appropriate for the workflow's purpose of building documentation previews for PR reviews. No change is needed.Likely an incorrect or invalid review comment.
.github/workflows/ci-main.yml (1)
38-39: Thetypechecktask is properly defined and configured. The turbo.json pipeline includes the task with correct dependencies (dependsOn: ["^build"]), and all workspace packages implement it viatsc --noEmit. The CI step will execute successfully..github/workflows/ci-autofix.yml (1)
43-44: Ensure thefmt:docsscript is defined in package.json with proper remark or documentation tooling dependencies installed.The new formatting step depends on the
fmt:docsscript existing in package.json and documentation tooling (such as remark, Prettier, or markdownlint) being available. This should be verified against the actual package.json configuration to prevent workflow failures.
| uses: consentdotio/github-actions/bundle-analysis-action@main | ||
| with: | ||
| base_dir: .bundle-base | ||
| current_dir: . | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} | ||
| pr_number: ${{ github.event.pull_request.number }} | ||
| skip_comment: false | ||
| fail_on_increase: false | ||
| header: "bundle-analysis" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
echo "=== Fetching action.yml from consentdotio/github-actions/bundle-analysis-action ==="
curl -s https://raw.githubusercontent.com/consentdotio/github-actions/main/bundle-analysis-action/action.yml
echo ""
echo "=== Checking for available releases/tags ==="
gh api repos/consentdotio/github-actions/releases --paginate --jq '.[] | {tag_name, published_at}' 2>/dev/null | head -20 || echo "Could not fetch releases via gh cli"
echo ""
echo "=== Trying alternative: fetch releases via curl ==="
curl -s https://api.github.com/repos/consentdotio/github-actions/releases | jq -r '.[] | "\(.tag_name) - \(.published_at)"' 2>/dev/null | head -10Repository: consentdotio/runners
Length of output: 3323
Pin the remote action to a specific commit SHA; the header parameter is valid.
The header: "bundle-analysis" input is correctly specified—it's a documented, optional input parameter with that exact default value. However, the action reference using @main remains a concern. The action repository has no published releases or tags, making SHA pinning the only way to ensure reproducible deployments and prevent unexpected breakage from main branch changes. Pin to a specific commit (e.g., consentdotio/github-actions/bundle-analysis-action@<commit-sha>).
🤖 Prompt for AI Agents
.github/workflows/analysis-bundle.yml lines 81-89: the workflow currently
references consentdotio/github-actions/bundle-analysis-action@main which should
be pinned to a specific commit SHA for reproducible runs; replace the @main ref
with the repository commit SHA (e.g.,
consentdotio/github-actions/bundle-analysis-action@<commit-sha>) by finding the
desired commit in that repo and updating the workflow file, then commit the
change so the action runs against the exact pinned commit; leave the header
input as-is.
…SHA for checkout - Updated the checkout step in the documentation deployment workflow to use the pull request head SHA when the event is a pull request, ensuring the correct branch is checked out for deployments.
Docs Preview
|
- Created a new reusable workflow for deploying documentation, allowing for more flexible configurations such as branch-specific alias assignments and change detection. - Updated the existing documentation deployment workflow to utilize the new reusable workflow, streamlining the deployment process and improving maintainability.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/deploy-docs.yml(1 hunks)
⏰ 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). (4)
- GitHub Check: 🏗️ Build Packages
- GitHub Check: 🧹 Lint & Type Check
- GitHub Check: autofix
- GitHub Check: 📦 Bundle Size Analysis
🔇 Additional comments (2)
.github/workflows/deploy-docs.yml (2)
85-87: Incorrect file and line number references in review comment.The review comment references
.github/workflows/deploy-docs.ymllines 85-87, but the code snippet shown (withgithub_app_id,github_app_private_key, andgithub_app_installation_id) actually appears in.github/workflows/deploy-docs-reusable.ymlat lines 99-101. The line numbers and file path do not match the actual codebase. The deploy-docs.yml file has only 85 lines and does not contain the referenced snippet.Likely an incorrect or invalid review comment.
81-122: The workflow has been refactored to use a reusable workflow (./.github/workflows/deploy-docs-reusable.yml) rather than a direct third-party action. The code snippet in this review comment does not match the current state of the file. Lines 81-122 contain secret definitions for the reusable workflow call, not the direct action call withconsentdotio/github-actions/docs-preview-action@mainshown in the review.Likely an incorrect or invalid review comment.
| # 🚀 Runner docs deployment workflow (Unified) | ||
| name: Deploy docs | ||
|
|
||
| on: | ||
| # 📌 Trigger on PRs that modify docs (build previews for reviews) | ||
| pull_request: | ||
| branches: | ||
| - "**" | ||
| # 📌 Trigger on pushes to main (production) and other branches (staging) | ||
| push: | ||
| branches: | ||
| - "**" | ||
| # 📌 Manual trigger for production deployments | ||
| workflow_dispatch: | ||
| inputs: | ||
| branch: | ||
| description: "Branch to deploy (main for production, or any branch for staging)" | ||
| required: true | ||
| type: string | ||
|
|
||
| permissions: | ||
| contents: read | ||
| issues: write | ||
| pull-requests: write | ||
| deployments: write | ||
|
|
||
| jobs: |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add documentation about required setup and prerequisites.
The workflow relies on external services (Vercel, consent.io GitHub app) and secrets without documenting prerequisite setup. Consider adding a comment block or referencing documentation that explains:
- How to set up the Vercel integration
- How to configure the consent.io GitHub app
- Which secrets need to be created and where
Optional: Add a documentation comment at the top of the file:
# 🚀 Runner docs deployment workflow (Unified)
name: Deploy docs
+
+# Prerequisites:
+# 1. Repository secrets must be configured:
+# - CONSENT_APP_ID: Consent.io GitHub App ID
+# - CONSENT_APP_PRIVATE_KEY: Consent.io GitHub App private key
+# - VERCEL_TOKEN: Vercel API token
+# - VERCEL_PROJECT_ID: Vercel project ID
+# - VERCEL_ORG_ID: Vercel organization ID
+# - CONSENT_GIT_TOKEN: Git token for consent.io repos
+# 2. Vercel project must be configured and linked to this repository
+# 3. Consent.io GitHub App must be installed on this repository🤖 Prompt for AI Agents
.github/workflows/deploy-docs.yml lines 1-27: Add a short top-of-file
documentation block describing required external integrations and secrets;
explicitly list Vercel integration setup steps or a link to docs, consent.io
GitHub app configuration steps or link, and enumerate required
repository/organization secrets (names and purpose) and where to configure them
(Repo Settings -> Secrets or Org Settings), so maintainers know prerequisites
before using the workflow.
| needs: setup | ||
| concurrency: | ||
| group: ${{ github.event_name == 'pull_request' && 'docs-preview-' || github.ref == 'refs/heads/main' && 'docs-production-' || 'docs-staging-' }}${{ github.event_name == 'pull_request' && github.ref || github.ref_name || github.event.inputs.branch }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Simplify or document the complex concurrency group expression.
Line 54 uses nested ternary operators across multiple lines, which is difficult to read and maintain. Consider either:
- Breaking the logic into separate steps within the job for clarity, or
- Adding inline comments explaining each branch of the conditional.
Recommended refactor: Add a setup step in the deploy job to compute the concurrency group explicitly:
deploy:
needs: setup
- concurrency:
- group: ${{ github.event_name == 'pull_request' && 'docs-preview-' || github.ref == 'refs/heads/main' && 'docs-production-' || 'docs-staging-' }}${{ github.event_name == 'pull_request' && github.ref || github.ref_name || github.event.inputs.branch }}
- cancel-in-progress: true
runs-on: ubuntu-latest
steps:
+ - id: compute-concurrency
+ run: |
+ if [ "${{ github.event_name }}" == "pull_request" ]; then
+ GROUP_PREFIX="docs-preview-"
+ GROUP_SUFFIX="${{ github.event.pull_request.number }}"
+ elif [ "${{ github.ref }}" == "refs/heads/main" ]; then
+ GROUP_PREFIX="docs-production-"
+ GROUP_SUFFIX="main"
+ else
+ GROUP_PREFIX="docs-staging-"
+ GROUP_SUFFIX="${{ github.ref_name || github.event.inputs.branch }}"
+ fi
+ echo "group=${GROUP_PREFIX}${GROUP_SUFFIX}" >> $GITHUB_OUTPUT
+ - name: 📥 Checkout repository
+ uses: actions/checkout@v4
+ with:
+ ref: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || github.event.inputs.branch || github.ref_name }}
+ fetch-depth: 0
+
+ concurrency:
+ group: ${{ needs.setup.outputs.concurrency_group }}
+ cancel-in-progress: trueAlternatively, add a comment above line 54 explaining the logic for future maintainers.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
.github/workflows/deploy-docs.yml lines 52-55: the concurrency.group expression
is a nested ternary that is hard to read and maintain; replace it by computing a
clear concurrency_group value in an earlier step (e.g., a small "setup
concurrency" step that sets an output or env var by checking github.event_name
and github.ref/ref_name with simple if/else logic or a short shell script), then
reference that output/env in concurrency.group, or alternatively add a concise
inline comment above the existing line describing each branch (pull_request ->
docs-preview-<ref>, main -> docs-production-<ref>, else -> docs-staging-<ref>)
so the conditional intent is explicit.
- Created a new changelog file detailing the initial release of the runners SDK, including features such as local and remote execution, CLI support, HTTP API orchestration, Playwright integration, TypeScript plugin, and schema extraction. - Highlighted core capabilities and provided example code snippets for better understanding and usage.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
.github/workflows/deploy-docs-reusable.yml(1 hunks).github/workflows/deploy-docs.yml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.9)
.github/workflows/deploy-docs.yml
78-78: input "check_template_changes" is typed as string by reusable workflow "./.github/workflows/deploy-docs-reusable.yml". bool value cannot be assigned
(expression)
🪛 YAMLlint (1.37.1)
.github/workflows/deploy-docs-reusable.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 132-132: too many blank lines (1 > 0)
(empty-lines)
⏰ 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). (3)
- GitHub Check: 🧹 Lint & Type Check
- GitHub Check: 🏗️ Build Packages
- GitHub Check: 📦 Bundle Size Analysis
🔇 Additional comments (5)
.github/workflows/deploy-docs-reusable.yml (2)
1-66: ✓ Workflow structure and configuration look sound.Permissions are appropriately scoped, inputs are well-documented with sensible defaults, and secrets are properly declared. The YAMLlint warning on line 3 is a false positive (the
on:keyword is valid YAML).
101-101: Clarify the scope ofgithub_app_installation_idbefore deciding on externalization.The hardcoded installation ID
81013186should be reconsidered only if this ID varies across environments or deployment contexts (dev, staging, production, or different organizations).GitHub app installation IDs are typically repository-specific and static once configured. If this ID:
- Is fixed for a single repository or organization → leave as-is; optionally add an inline comment for clarity
- Should vary per environment or repository → externalize as a repository secret (
${{ secrets.GITHUB_APP_INSTALLATION_ID }})- Is used across multiple environments in this workflow → parameterize via workflow inputs
Verify the intended usage pattern before implementing changes. If truly static, no action is required; if environment-specific, externalize as a secret.
.github/workflows/deploy-docs.yml (3)
1-25: ✓ Trigger and permissions are appropriately configured.The workflow triggers on all PRs and pushes (which is reasonable for documentation), includes manual dispatch, and permissions align with deployment needs.
27-50: ✓ Setup job conditional logic correctly maps deployment targets.The three-way branching (PR → preview, main → production, other → staging) is well-structured and properly sets alias_domains, target, and header for downstream consumption. The shell syntax on line 46 using
||fallback is correct.
51-85: ✓ Deploy job orchestration and variable passing are correct.The concurrency group correctly distinguishes between preview, production, and staging deployments. Variable passing from the setup job is accurate, and all secrets are properly forwarded to the reusable workflow.
The actionlint warning at line 78 regarding
check_template_changes: "true"is a false positive; the reusable workflow declares this as a string input (type: string) and "true" is a valid string literal in GitHub Actions YAML.
|
|
||
| - name: ▲ Runner Deployment | ||
| id: runner-docs | ||
| uses: consentdotio/github-actions/docs-preview-action@main |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check if this is a real action by searching for references to it
rg "consentdotio/github-actions" --type yamlRepository: consentdotio/runners
Length of output: 46
🌐 Web query:
consentdotio/github-actions docs-preview-action versions releases
💡 Result:
I can look that up — do you mean the GitHub repository consentdotio/docs-preview-action (or a different owner/repo)? Confirm the exact repo name and whether you want tags, releases, or Marketplace versions, and I’ll fetch the release/version list.
🏁 Script executed:
# Find and read the workflow file
find . -name "deploy-docs-reusable.yml" -type fRepository: consentdotio/runners
Length of output: 108
🏁 Script executed:
# Search for consentdotio anywhere in the repo
rg "consentdotio" --type yamlRepository: consentdotio/runners
Length of output: 46
🏁 Script executed:
# List all yaml files to understand the repo structure
fd -e yml -e yaml | head -20Repository: consentdotio/runners
Length of output: 98
🏁 Script executed:
# Read the workflow file around line 95
cat -n ./.github/workflows/deploy-docs-reusable.yml | sed -n '90,105p'Repository: consentdotio/runners
Length of output: 706
🏁 Script executed:
# Check if there's documentation about the action
find . -name "*.md" -type f | xargs rg "docs-preview-action" 2>/dev/nullRepository: consentdotio/runners
Length of output: 48
🏁 Script executed:
# Check git history to see if this reference has been stable
git log --oneline -n 20 -- ./.github/workflows/deploy-docs-reusable.yml 2>/dev/null || echo "Git history not available"Repository: consentdotio/runners
Length of output: 137
🏁 Script executed:
# Check if there's a docs-preview-action action file in the repo
find . -path "*/github-actions/*" -o -path "*/actions/*" -o -name "*docs-preview*" 2>/dev/nullRepository: consentdotio/runners
Length of output: 115
🌐 Web query:
consentdotio github-actions repository docs-preview-action releases
💡 Result:
I can look that up — do you want me to search GitHub for the consentdotio/docs-preview-action repository and list its releases now?
🏁 Script executed:
# Check if there's a local actions directory
find . -type d -name "actions" -o -type d -name ".github/actions"Repository: consentdotio/runners
Length of output: 97
🏁 Script executed:
# Look at the broader GitHub workflows context
ls -la .github/workflows/Repository: consentdotio/runners
Length of output: 508
🏁 Script executed:
# Check if there are any comments or documentation in the workflow about the action
cat ./.github/workflows/deploy-docs-reusable.yml | head -20Repository: consentdotio/runners
Length of output: 554
🏁 Script executed:
# Read the full workflow file
cat ./.github/workflows/deploy-docs-reusable.ymlRepository: consentdotio/runners
Length of output: 3831
Pin the GitHub action to a specific version; @main is unsafe for production workflows.
This workflow pins all other actions to specific versions (actions/checkout@v4, actions/setup-node@v4, pnpm/action-setup@v4) but uses @main for the custom docs-preview-action. Using @main introduces stability and security risks—the action could change unexpectedly, breaking deployments or introducing vulnerabilities. Pin to a specific release tag instead (e.g., @v1.0.0).
Verify the available version tags in the consentdotio/github-actions repository and update accordingly.
🤖 Prompt for AI Agents
.github/workflows/deploy-docs-reusable.yml around line 95: the workflow uses
consentdotio/github-actions/docs-preview-action@main which is unsafe for
production; replace @main with a specific released tag (e.g., @v1.0.0) by
checking the consentdotio/github-actions repository for available version tags
or releases and update the workflow to pin the action to that exact tag or
commit SHA to ensure stability and security.
| comment_marker_prefix: "runner" | ||
|
|
There was a problem hiding this comment.
Remove trailing blank line at end of file.
YAMLlint flags excess blank lines. Remove the trailing blank line to conform to style standards.
🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 132-132: too many blank lines (1 > 0)
(empty-lines)
🤖 Prompt for AI Agents
.github/workflows/deploy-docs-reusable.yml around lines 131-132: the file ends
with an extra trailing blank line which causes yamllint to flag excess blank
lines; remove the final empty line so the file ends immediately after the last
line containing 'comment_marker_prefix: "runner"' (ensure no additional newline
beyond a single terminating newline if your editor inserts one).
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (1)
.github/workflows/deploy-docs.yml (1)
53-55: Simplify or document the nested ternary concurrency group expression.The nested ternary operators are difficult to read and maintain. This was flagged in the prior review and remains unaddressed. Consider either extracting this into a separate setup step or adding an inline comment.
Option 1 (recommended): Add an inline comment explaining each branch:
concurrency: + # PR previews → docs-preview-<sha>; main → docs-production-main; others → docs-staging-<branch> group: ${{ github.event_name == 'pull_request' && 'docs-preview-' || github.ref == 'refs/heads/main' && 'docs-production-' || 'docs-staging-' }}${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || github.ref_name || github.event.inputs.branch }}Option 2 (if concurrency becomes more complex): Extract concurrency group computation into the setup job:
Compute
concurrency_groupas an output in the setup job using simple if/else logic, then reference it here asgroup: ${{ needs.setup.outputs.concurrency_group }}.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
.github/workflows/deploy-docs-reusable.yml(1 hunks).github/workflows/deploy-docs.yml(1 hunks)changelog/2025-12-01-v1.0.0.mdx(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.9)
.github/workflows/deploy-docs.yml
78-78: input "check_template_changes" is typed as string by reusable workflow "./.github/workflows/deploy-docs-reusable.yml". bool value cannot be assigned
(expression)
🪛 YAMLlint (1.37.1)
.github/workflows/deploy-docs-reusable.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 132-132: too many blank lines (1 > 0)
(empty-lines)
⏰ 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). (3)
- GitHub Check: 🧹 Lint & Type Check
- GitHub Check: 🏗️ Build Packages
- GitHub Check: 📦 Bundle Size Analysis
🔇 Additional comments (11)
.github/workflows/deploy-docs.yml (3)
1-26: Missing documentation of required secrets and external integrations.This workflow relies on several repository secrets (CONSENT_APP_ID, CONSENT_APP_PRIVATE_KEY, VERCEL_TOKEN, etc.) and external service integrations (Vercel, Consent.io GitHub App) that are not documented in the workflow file. Maintainers need to understand prerequisites before using this workflow.
Add a documentation block at the top of the file that explicitly lists required secrets, their purpose, and setup instructions:
# 🚀 Runner docs deployment workflow (Unified) name: Deploy docs + +# Prerequisites: +# 1. Repository secrets must be configured: +# - CONSENT_APP_ID: Consent.io GitHub App ID +# - CONSENT_APP_PRIVATE_KEY: Consent.io GitHub App private key +# - VERCEL_TOKEN: Vercel API token +# - VERCEL_PROJECT_ID: Vercel project ID +# - VERCEL_ORG_ID: Vercel organization ID +# - CONSENT_GIT_TOKEN: Git token for consent.io repos +# 2. Vercel project must be configured and linked to this repository +# 3. Consent.io GitHub App must be installed on this repository
28-50: Setup job logic and outputs are well-structured.The conditional logic correctly routes PR previews, production deployments, and staging deployments with appropriate aliases and headers. The use of outputs to wire into the deploy job is clean.
72-78: No type mismatch exists—inputs are correctly defined as strings.The reusable workflow (deploy-docs-reusable.yml, lines 34–47) already defines
only_if_changedandcheck_template_changeswithtype: string, which matches the string literals passed in deploy-docs.yml (lines 72, 78). The values"true"and"false"are standard string-based boolean representations in GitHub Actions and are properly handled by the downstream action.Likely an incorrect or invalid review comment.
.github/workflows/deploy-docs-reusable.yml (2)
3-47: Workflow input definitions are well-structured; false positive linting warning.The workflow_call structure and input definitions are correct. The YAMLlint warning about truthy values on line 3 is a false positive;
on: workflow_call:is standard GitHub Actions syntax.Note: The type definitions for
only_if_changedandcheck_template_changes(lines 34–47) astype: stringalign with the pragmatic approach of passing boolean-like strings in GitHub Actions. Ensure consistency with the caller (deploy-docs.yml) and that the downstream action can parse these string values.
71-91: Setup steps are well-configured for reproducible builds.The checkout, node setup, and pnpm installation are correctly structured with frozen-lockfile for reproducibility. Full history fetch (fetch-depth: 0) is appropriate for docs builds that may require commit metadata.
changelog/2025-12-01-v1.0.0.mdx (6)
1-18: Front matter structure is well-formed and comprehensive.The YAML metadata is properly formatted with all expected fields for a changelog release entry.
26-54: Runner SDK example code is well-structured and instructive.The TypeScript example demonstrates proper SDK usage with Zod validation, Playwright integration, and the expected runner result format.
61-62: CLI example demonstrates practical usage with correct syntax.The Bash example shows a realistic command invocation with proper flag and JSON input formatting.
73-89: HTTP orchestrator examples correctly demonstrate framework integration patterns.Both Nitro and Hono examples follow their respective framework conventions and would serve as effective integration guides.
95-113: Playwright integration example demonstrates browser automation correctly.The TypeScript code shows proper usage of the browser context with standard Playwright operations and correct runner structure.
123-131: No changes needed—bullet formatting is already standardized.The Core Capabilities section correctly uses asterisk bullets, which is the established standard across the codebase for feature and capability lists. Verification confirms consistent use of asterisks throughout the documentation (docs/introduction.mdx, README.md, and other mdx files), with hyphens reserved for metadata and frontmatter.
| - name: ▲ Runner Deployment | ||
| id: runner-docs | ||
| uses: consentdotio/github-actions/docs-preview-action@main | ||
| with: | ||
| # Auth | ||
| GITHUB_TOKEN: ${{ github.token }} | ||
| github_app_id: ${{ secrets.CONSENT_APP_ID }} | ||
| github_app_private_key: ${{ secrets.CONSENT_APP_PRIVATE_KEY }} | ||
| github_app_installation_id: 81013186 | ||
|
|
||
| # Production target | ||
| target: ${{ inputs.target }} | ||
|
|
||
| # Comment behavior | ||
| header: ${{ inputs.header }} | ||
| append: "true" | ||
| hide_details: "true" | ||
|
|
||
| # Vercel | ||
| vercel_token: ${{ secrets.VERCEL_TOKEN }} | ||
| vercel_project_id: ${{ secrets.VERCEL_PROJECT_ID }} | ||
| vercel_org_id: ${{ secrets.VERCEL_ORG_ID }} | ||
|
|
||
| assign_alias_on_branch: ${{ inputs.assign_alias_on_branch }} | ||
| alias_domains: ${{ inputs.alias_domains }} | ||
|
|
||
| # Branch deployment policies | ||
| deploy_on_push_branches: ${{ inputs.deploy_on_push_branches }} | ||
| deploy_on_pr_base_branches: ${{ inputs.deploy_on_pr_base_branches }} | ||
|
|
||
| # Orchestration & gating | ||
| consent_git_token: ${{ secrets.CONSENT_GIT_TOKEN }} | ||
| docs_template_repo: consentdotio/runner-docs | ||
| only_if_changed: ${{ inputs.only_if_changed }} | ||
| change_globs: ${{ inputs.change_globs }} | ||
| check_template_changes: ${{ inputs.check_template_changes }} |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Hardcoded github_app_installation_id needs documentation or configuration.
Line 101 hardcodes github_app_installation_id: 81013186, which is environment/organization-specific. This should either be:
- Documented with a comment explaining why this specific ID is used,
- Extracted as a workflow input for flexibility, or
- Kept as a constant if it's truly organization-wide, but documented.
Add a comment explaining the significance of this ID:
github_app_id: ${{ secrets.CONSENT_APP_ID }}
github_app_private_key: ${{ secrets.CONSENT_APP_PRIVATE_KEY }}
+ # Organization-wide Consent.io GitHub App installation ID for runner-docs
github_app_installation_id: 81013186Alternatively, consider extracting this as a workflow input if different repositories or organizations need different installation IDs.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: ▲ Runner Deployment | |
| id: runner-docs | |
| uses: consentdotio/github-actions/docs-preview-action@main | |
| with: | |
| # Auth | |
| GITHUB_TOKEN: ${{ github.token }} | |
| github_app_id: ${{ secrets.CONSENT_APP_ID }} | |
| github_app_private_key: ${{ secrets.CONSENT_APP_PRIVATE_KEY }} | |
| github_app_installation_id: 81013186 | |
| # Production target | |
| target: ${{ inputs.target }} | |
| # Comment behavior | |
| header: ${{ inputs.header }} | |
| append: "true" | |
| hide_details: "true" | |
| # Vercel | |
| vercel_token: ${{ secrets.VERCEL_TOKEN }} | |
| vercel_project_id: ${{ secrets.VERCEL_PROJECT_ID }} | |
| vercel_org_id: ${{ secrets.VERCEL_ORG_ID }} | |
| assign_alias_on_branch: ${{ inputs.assign_alias_on_branch }} | |
| alias_domains: ${{ inputs.alias_domains }} | |
| # Branch deployment policies | |
| deploy_on_push_branches: ${{ inputs.deploy_on_push_branches }} | |
| deploy_on_pr_base_branches: ${{ inputs.deploy_on_pr_base_branches }} | |
| # Orchestration & gating | |
| consent_git_token: ${{ secrets.CONSENT_GIT_TOKEN }} | |
| docs_template_repo: consentdotio/runner-docs | |
| only_if_changed: ${{ inputs.only_if_changed }} | |
| change_globs: ${{ inputs.change_globs }} | |
| check_template_changes: ${{ inputs.check_template_changes }} | |
| - name: ▲ Runner Deployment | |
| id: runner-docs | |
| uses: consentdotio/github-actions/docs-preview-action@main | |
| with: | |
| # Auth | |
| GITHUB_TOKEN: ${{ github.token }} | |
| github_app_id: ${{ secrets.CONSENT_APP_ID }} | |
| github_app_private_key: ${{ secrets.CONSENT_APP_PRIVATE_KEY }} | |
| # Organization-wide Consent.io GitHub App installation ID for runner-docs | |
| github_app_installation_id: 81013186 | |
| # Production target | |
| target: ${{ inputs.target }} | |
| # Comment behavior | |
| header: ${{ inputs.header }} | |
| append: "true" | |
| hide_details: "true" | |
| # Vercel | |
| vercel_token: ${{ secrets.VERCEL_TOKEN }} | |
| vercel_project_id: ${{ secrets.VERCEL_PROJECT_ID }} | |
| vercel_org_id: ${{ secrets.VERCEL_ORG_ID }} | |
| assign_alias_on_branch: ${{ inputs.assign_alias_on_branch }} | |
| alias_domains: ${{ inputs.alias_domains }} | |
| # Branch deployment policies | |
| deploy_on_push_branches: ${{ inputs.deploy_on_push_branches }} | |
| deploy_on_pr_base_branches: ${{ inputs.deploy_on_pr_base_branches }} | |
| # Orchestration & gating | |
| consent_git_token: ${{ secrets.CONSENT_GIT_TOKEN }} | |
| docs_template_repo: consentdotio/runner-docs | |
| only_if_changed: ${{ inputs.only_if_changed }} | |
| change_globs: ${{ inputs.change_globs }} | |
| check_template_changes: ${{ inputs.check_template_changes }} |
🤖 Prompt for AI Agents
.github/workflows/deploy-docs-reusable.yml lines 93 to 128: the
github_app_installation_id is hardcoded to 81013186 which is organization/repo
specific; either document why this exact ID is required or make it configurable.
Add a concise comment above that line explaining the ID’s scope/validity and why
it is safe to hardcode (if it truly is org-wide), or refactor the workflow to
accept an input (e.g., github_app_installation_id) and replace the hardcoded
value with that input, updating the workflow inputs and README usage examples
accordingly.
|
|
||
| # Branding customization | ||
| comment_marker_prefix: "runner" | ||
|
|
There was a problem hiding this comment.
Remove trailing blank lines.
YAMLlint reports trailing blank lines at the end of the file. Remove them to maintain consistent formatting.
# Branding customization
comment_marker_prefix: "runner"
-📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Branding customization | |
| comment_marker_prefix: "runner" | |
| # Branding customization | |
| comment_marker_prefix: "runner" |
🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 132-132: too many blank lines (1 > 0)
(empty-lines)
🤖 Prompt for AI Agents
.github/workflows/deploy-docs-reusable.yml lines 129-132: the file currently
ends with one or more trailing blank lines which YAMLlint flags; remove the
extra blank lines at the end of the file so the file ends immediately after the
last YAML line (ensure no empty newline-only lines remain after the final
content).
| ### TypeScript Plugin | ||
|
|
||
| Get full type safety and IntelliSense support with the TypeScript plugin. The plugin validates runner structure and provides helpful autocomplete. | ||
|
|
||
| ### Schema Extraction | ||
|
|
||
| Automatically extract runner schemas for validation and documentation. The schema extractor analyzes your runner functions and generates Zod schemas. |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider adding code examples for feature completeness and consistency.
The TypeScript Plugin and Schema Extraction sections lack code examples, while all preceding feature subsections (Runner SDK, CLI, Orchestrator, Playwright) include them. Adding examples for these features would improve consistency and help readers understand their capabilities.
For TypeScript Plugin, consider showing a plugin directive or configuration:
/// <reference types="runners/plugin" />For Schema Extraction, consider showing the schema output format or extraction usage.
🤖 Prompt for AI Agents
changelog/2025-12-01-v1.0.0.mdx lines 115-121: add short code examples to the
TypeScript Plugin and Schema Extraction subsections to match the existing
sections' pattern; for the TypeScript Plugin include a one-line example showing
how to enable typings (e.g., a plugin directive or tsconfig reference) and a
brief note on where to place it, and for Schema Extraction include a minimal
snippet or sample output showing the generated schema shape or the extraction
invocation and resulting Zod schema so readers can quickly see usage and format.
| * **Browser automation**: Optional Playwright integration when needed | ||
| * **Zero configuration**: Sensible defaults, configure only what you need | ||
|
|
||
| <ContributorBlock usernames={["BurnedChris"]} title="Thank you to our contributors" /> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for ContributorBlock component definition
rg 'export.*ContributorBlock|function ContributorBlock|const ContributorBlock' -t ts -t tsx -t js -t jsx -A 2
# Check the MDX file itself for imports
echo "=== Checking changelog file for imports ==="
head -50 changelog/2025-12-01-v1.0.0.mdx
# Search for MDX configuration and component context
echo "=== Searching for MDX components configuration ==="
fd -type f -name '*mdx*config*' -o -name '*mdx*' -path '*/config/*'
# Check common MDX wrapper/provider locations
echo "=== Checking for MDX component providers ==="
rg 'ContributorBlock' -t ts -t tsx -t js -t jsx --max-count=20Repository: consentdotio/runners
Length of output: 1692
🏁 Script executed:
# View the file around line 132
echo "=== Content around line 132 ==="
sed -n '125,140p' changelog/2025-12-01-v1.0.0.mdx
# Count total lines to understand file structure
echo "=== File statistics ==="
wc -l changelog/2025-12-01-v1.0.0.mdx
# Search for ContributorBlock without type restrictions
echo "=== Searching for ContributorBlock component ==="
rg 'ContributorBlock' -B 2 -A 2
# Check for MDX wrapper/provider files
echo "=== Checking for MDX wrapper components ==="
find . -name '*mdx*' -o -name '*wrapper*' -o -name '*provider*' | grep -E '\.(tsx?|jsx?)$' | head -20
# Check if there's a layout or MDX configuration
echo "=== Checking root and common config locations ==="
ls -la | grep -E 'mdx|config|next|astro'
cat mdx.config.js 2>/dev/null || cat next.config.js 2>/dev/null || echo "No standard config found"Repository: consentdotio/runners
Length of output: 1213
🏁 Script executed:
# Check the runners config
echo "=== runners.config.ts ==="
cat runners.config.ts
# Search for any MDX-related build configuration
echo "=== Searching for MDX build/processing configuration ==="
rg 'mdx|MDX|component' runners.config.ts
# Look for layout files or wrappers that might provide components
echo "=== Checking for layout/wrapper files ==="
fd -e tsx -e ts -e jsx -e js | grep -iE 'layout|wrapper|provider|mdx' | head -20
# Search for where ContributorBlock might be defined as a global component
echo "=== Searching all TypeScript/JSX files for ContributorBlock definition ==="
fd -e tsx -e ts -e jsx -e js -x rg 'ContributorBlock' {} \;
# Check if there's a components directory
echo "=== Looking for components directory ==="
find . -type d -name 'component*' -o -type d -name 'mdx' 2>/dev/nullRepository: consentdotio/runners
Length of output: 544
🏁 Script executed:
# Check the components directory
echo "=== Components in ./packages/shared/cli/src/components ==="
find ./packages/shared/cli/src/components -type f
# Look for package.json files that might configure MDX/docs
echo "=== Searching for package.json with MDX/docs configuration ==="
find . -name 'package.json' -exec grep -l 'mdx\|docs\|changelog' {} \;
# Check root package.json for build scripts
echo "=== Root package.json scripts and dependencies ==="
cat package.json | grep -A 20 '"scripts"' | head -30
cat package.json | grep -A 30 '"dependencies\|devDependencies"' | head -50
# Search for astro config (common for MDX docs)
echo "=== Checking for Astro or other documentation tools ==="
find . -maxdepth 2 -name 'astro.config.*' -o -name '.astrorc*'
ls -la | grep -E 'astro|docs'
# Final check: search entire repo for ContributorBlock
echo "=== Final search for ContributorBlock anywhere in repo ==="
rg 'ContributorBlock' --type-add 'mdx:*.mdx' -t mdxRepository: consentdotio/runners
Length of output: 1987
Define and import the ContributorBlock component or remove its usage.
The ContributorBlock component is used on line 132 but is not defined anywhere in the codebase and is not imported in the MDX file. This will cause a build or render failure. Either define the component (likely in ./packages/shared/cli/src/components/), import it at the top of the MDX file, or remove the component usage if it's no longer needed.
🤖 Prompt for AI Agents
In changelog/2025-12-01-v1.0.0.mdx around line 132 the file references
<ContributorBlock ... /> but the component is not defined or imported, which
will break the build; fix by either (a) creating and exporting ContributorBlock
in the shared components package (e.g., ./packages/shared/cli/src/components/)
and then importing it into this MDX file, (b) importing the existing
ContributorBlock from its correct module path at the top of the MDX file if it
already exists, or (c) removing the <ContributorBlock ... /> usage from the MDX
if the block is no longer needed; ensure exports and import paths are correct
and that the component is a default or named export matching your import.
- Removed push trigger for main and other branches, focusing on pull requests and manual dispatch for deployments. - Simplified alias domain assignments and adjusted target and header outputs based on event types. - Enhanced concurrency handling for deployment jobs, ensuring clearer management of deployment groups.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/deploy-docs.yml (1)
40-42: Note: Past feedback on concurrency complexity remains unaddressed.The prior review suggested simplifying the nested ternary on line 41 by either computing the concurrency group in the setup job or adding an inline comment. This remains present in the current version. While the expression is functionally correct, it impacts readability. This is a low-priority nitpick, but consider addressing in a follow-up if you refactor this workflow.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/deploy-docs.yml(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.9)
.github/workflows/deploy-docs.yml
65-65: input "check_template_changes" is typed as string by reusable workflow "./.github/workflows/deploy-docs-reusable.yml". bool value cannot be assigned
(expression)
⏰ 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). (3)
- GitHub Check: 🧹 Lint & Type Check
- GitHub Check: 🏗️ Build Packages
- GitHub Check: 📦 Bundle Size Analysis
| changelog/** | ||
| packages/*/src/** | ||
| packages/*/package.json | ||
| check_template_changes: "true" |
There was a problem hiding this comment.
Fix input type mismatch: check_template_changes must be boolean, not string.
Line 65 passes "true" (string) but the reusable workflow expects a boolean type. This will cause the workflow to fail or behave unexpectedly.
Apply this diff to remove the quotes:
- check_template_changes: "true"
+ check_template_changes: true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| check_template_changes: "true" | |
| check_template_changes: true |
🧰 Tools
🪛 actionlint (1.7.9)
65-65: input "check_template_changes" is typed as string by reusable workflow "./.github/workflows/deploy-docs-reusable.yml". bool value cannot be assigned
(expression)
🤖 Prompt for AI Agents
.github/workflows/deploy-docs.yml around line 65: the input
check_template_changes is passed as a string ("true") but the reusable workflow
expects a boolean; change the value to a bare boolean true (remove the quotes)
so YAML emits a boolean rather than a string, ensuring the input type matches
the called workflow's schema.
1 participant
Overview
Please describe the change here
Related Issue
Fixes # (issue)
Type of Change
Implementation Details
Key Changes
Technical Notes
Testing
Test Plan
Scenario 1: What to test
// Example code or steps✓ Expected: What should happen
Scenario 2: What to test
// Example code or steps✓ Expected: What should happen
Edge Cases
Visual Changes
Checklist
Required
Breaking Changes
Changes:
Migration:
Summary by CodeRabbit
Chores
Documentation
Workflow Changes
✏️ Tip: You can customize this high-level summary in your review settings.