Implement Awesome GitHub site MVP#755
Conversation
|
Warning Review limit reached
More reviews will be available in 10 minutes and 28 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (18)
📝 WalkthroughWalkthroughThis PR scaffolds a new Astro-based static website for the repository. It introduces a complete build pipeline (GitHub Actions, npm setup, Astro config), foundational layout and styling components, three informational pages (homepage, why-this-exists, references), and supporting documentation and gitignore rules. ChangesAwesome GitHub Site Launch
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 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 |
There was a problem hiding this comment.
Code Review
This pull request bootstraps the Phase 1 MVP for the Awesome GitHub website using Astro, adding configuration files, a base layout, global styles, and three core pages (Home, Why this exists, and References). The primary feedback highlights a critical issue where directly concatenating import.meta.env.BASE_URL (which defaults to /) with relative paths results in double slashes, leading to broken protocol-relative URLs in browsers. Normalizing the base URL by stripping its trailing slash is recommended across multiple pages and layouts. Additionally, an unused base variable in why-this-exists.astro should be removed.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| const base = import.meta.env.BASE_URL; | ||
| const pathname = Astro.url.pathname.replace(base, "/"); |
There was a problem hiding this comment.
When import.meta.env.BASE_URL is / (the default root path), concatenating it directly with relative paths (e.g., ${base}why-this-exists/) results in double slashes (e.g., //why-this-exists/). Browsers interpret double leading slashes as protocol-relative URLs, which will break navigation and asset loading during local development or when hosted at the root domain.
To prevent this, normalize the base URL by removing any trailing slash so that paths can be constructed safely with a single leading slash.
const base = import.meta.env.BASE_URL;
const cleanBase = base.replace(/\/$/, "");
const pathname = Astro.url.pathname.replace(base, "/");
| <head> | ||
| <meta charset="utf-8" /> | ||
| <meta name="viewport" content="width=device-width, initial-scale=1" /> | ||
| <link rel="icon" href={`${base}favicon.svg`} type="image/svg+xml" /> |
| <a href={`${base}why-this-exists/`} aria-current={pathname === "/why-this-exists/" ? "page" : undefined} | ||
| >Why this exists</a | ||
| > | ||
| <a href={`${base}references/`} aria-current={pathname === "/references/" ? "page" : undefined} | ||
| >References</a | ||
| > |
There was a problem hiding this comment.
Use the normalized cleanBase variable to prevent protocol-relative URLs for navigation links.
<a href={`${cleanBase}/why-this-exists/`} aria-current={pathname === "/why-this-exists/" ? "page" : undefined}
>Why this exists</a
>
<a href={`${cleanBase}/references/`} aria-current={pathname === "/references/" ? "page" : undefined}
>References</a
>
| const base = import.meta.env.BASE_URL; | ||
| --- |
| <a class="button primary" href={`${base}why-this-exists/`}>Why this exists</a> | ||
| <a class="button secondary" href={`${base}references/`}>Browse references</a> |
| const base = import.meta.env.BASE_URL; | ||
| --- |
| awesome-copilot website source | ||
| <span>Source tree used to understand the Astro and content layout patterns.</span> | ||
| </a> | ||
| <a class="ref" href={`${base}llms.txt`}> |
| const base = import.meta.env.BASE_URL; | ||
| --- |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (2)
website/package.json (1)
6-10: ⚡ Quick winAdd standard
lint,test, andformatscripts for org consistency.Great MVP start — just missing the usual script trio expected by repo standards. Adding them now keeps CI and local workflows tidy.
As per coding guidelines, "Ensure scripts follow org standards (lint, test, build, format)."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@website/package.json` around lines 6 - 10, The package.json scripts object only contains "dev", "build", and "preview" — add the standard org scripts "lint", "test", and "format" to that same "scripts" map so CI and local workflows are consistent; set "lint" to the repo-standard linter command with auto-fix enabled, "test" to the configured test runner command, and "format" to the project's formatter write command, and verify the commands match your repo's existing tooling and CI expectations.website/src/styles/global.css (1)
1-19: ⚖️ Poor tradeoffConsider adding light mode support.
The design system currently defines only a dark colour scheme. Whilst dark themes are brilliant (and quite stylish), some users may prefer a light mode for readability or personal preference. Since this is MVP phase 1, this could be deferred to phase 2, but it's worth flagging for future consideration!
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@website/src/styles/global.css` around lines 1 - 19, Add an explicit light-mode set of CSS custom properties so the UI can switch from the current dark theme; create a selector (e.g., [data-theme="light"] or `@media` (prefers-color-scheme: light)) that overrides the same variables defined in :root (--bg, --bg-elevated, --bg-soft, --border, --text, --muted, --accent, --accent-2, --accent-3, --shadow, --radius-*, --max-width, --serif, --sans) with light-friendly values, keep the existing :root dark definitions intact, and ensure your app/toggle can switch the data-theme attribute (or rely on prefers-color-scheme) so components consuming those variables automatically render in light mode.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/awesome-github-site.yml:
- Around line 3-14: Add a manual dispatch trigger to the workflow by updating
the on: block to include workflow_dispatch with explicit inputs; specifically
add a workflow_dispatch section that defines at least required inputs such as a
"requested_by" (string), "reason" (string), and a boolean like "run_ci"
(boolean) so runs can be manually audited and controlled. Modify the existing
on: block (near the pull_request and push entries) to include this new
workflow_dispatch inputs structure and ensure descriptions/defaults are provided
for each input to satisfy governance requirements.
In `@website/README.md`:
- Around line 1-17: The frontmatter block at the top of README.md is missing the
required language field; update the YAML frontmatter (the document metadata
block containing title "Awesome GitHub Site" and fields like
version/created_date) to include a language entry (e.g., language: "en" or
another appropriate locale) so the markdown docs comply with the repository
guideline requiring language in frontmatter.
In `@website/src/pages/why-this-exists.astro`:
- Line 3: Remove the unused constant by deleting the declaration "const base =
import.meta.env.BASE_URL;" from the file; locate the top-level declaration of
the variable named base and remove it (and any now-unreferenced import or
comment tied only to that line) so the page no longer defines an unused symbol.
In `@website/src/styles/global.css`:
- Around line 27-29: The global CSS currently forces smooth scrolling via the
html selector (scroll-behavior: smooth) which ignores users'
prefers-reduced-motion setting; update the stylesheet to respect the
prefers-reduced-motion media query by keeping scroll-behavior: smooth for
default but overriding it to scroll-behavior: auto (or unset) inside `@media`
(prefers-reduced-motion: reduce) so users who opt for reduced motion are not
subjected to smooth scrolling.
---
Nitpick comments:
In `@website/package.json`:
- Around line 6-10: The package.json scripts object only contains "dev",
"build", and "preview" — add the standard org scripts "lint", "test", and
"format" to that same "scripts" map so CI and local workflows are consistent;
set "lint" to the repo-standard linter command with auto-fix enabled, "test" to
the configured test runner command, and "format" to the project's formatter
write command, and verify the commands match your repo's existing tooling and CI
expectations.
In `@website/src/styles/global.css`:
- Around line 1-19: Add an explicit light-mode set of CSS custom properties so
the UI can switch from the current dark theme; create a selector (e.g.,
[data-theme="light"] or `@media` (prefers-color-scheme: light)) that overrides the
same variables defined in :root (--bg, --bg-elevated, --bg-soft, --border,
--text, --muted, --accent, --accent-2, --accent-3, --shadow, --radius-*,
--max-width, --serif, --sans) with light-friendly values, keep the existing
:root dark definitions intact, and ensure your app/toggle can switch the
data-theme attribute (or rely on prefers-color-scheme) so components consuming
those variables automatically render in light mode.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 361c96f3-c3ae-4f7f-a0de-6770bd0a7a63
⛔ Files ignored due to path filters (2)
website/package-lock.jsonis excluded by!**/package-lock.jsonwebsite/public/favicon.svgis excluded by!**/*.svg
📒 Files selected for processing (11)
.github/workflows/awesome-github-site.ymlwebsite/.gitignorewebsite/README.mdwebsite/astro.config.mjswebsite/package.jsonwebsite/public/llms.txtwebsite/src/layouts/BaseLayout.astrowebsite/src/pages/index.astrowebsite/src/pages/references.astrowebsite/src/pages/why-this-exists.astrowebsite/src/styles/global.css
📜 Review details
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{js,ts,tsx,php,py,json,yaml,yml,env,conf,config}
📄 CodeRabbit inference engine (AGENTS.md)
Never output secrets. Treat production and customer data as sensitive. Follow the OWASP top 10 for web security
Files:
website/package.json
**/*.{md,js,ts,jsx,tsx,json,php,yml,yaml}
📄 CodeRabbit inference engine (CLAUDE.md)
Use UK English throughout (optimise, organisation, colour, behaviour)
Files:
website/package.jsonwebsite/README.md
**/package.json
⚙️ CodeRabbit configuration file
**/package.json: Review package.json:
- Check for security vulnerabilities and outdated packages.
- Ensure scripts are documented with clear, descriptive names.
- Validate semantic versioning and proper version pinning.
- Confirm devDependencies vs dependencies separation.
- Ensure scripts follow org standards (lint, test, build, format).
Files:
website/package.json
**/.github/workflows/*.yml
⚙️ CodeRabbit configuration file
**/.github/workflows/*.yml: Review GitHub Actions workflows for this governance repo:
- Security: check for least-privilege permissions (use
permissions:at job level, default to read-only).- Secret handling: ensure secrets are passed via env vars, not interpolated directly into run: steps to prevent injection.
- Action pinning: prefer SHA-pinned actions over mutable tags (e.g.
actions/checkout@v4is acceptable; SHA pins are better).- No
pull_request_targetwith untrusted code execution unless explicitly justified.- Avoid storing sensitive outputs as unmasked step outputs.
- Check for reusable workflow patterns and matrix strategies where appropriate.
- Validate
on:triggers: ensure branch/path filters are present to avoid unnecessary runs.- Confirm workflows are documented, DRY, and maintainable.
- Ensure agent-triggered workflows use
workflow_dispatchwith defined inputs.
Files:
.github/workflows/awesome-github-site.yml
**/*.md
📄 CodeRabbit inference engine (.github/instructions/markdown.instructions.md)
**/*.md: Use one H1 (#) per file; keep heading levels sequential (never skip from H2 to H4)
Use fenced code blocks with explicit language tags (bash,yaml,markdown, etc.)
Keep links relative for in-repo files; verify they resolve before merging
Use1.for ordered lists and-for unordered lists
Keep all wording in UK English (optimise, organisation, colour, behaviour, analyse)
Do not add areferences:frontmatter field — use inline links or a footer section instead
Blank lines before and after headings, code blocks, and block-level elements
Maximum line length: 120 characters (soft limit; prefer wrapping at natural sentence boundaries)
All.mdfiles in this repository should include YAML frontmatter with required fields: file_type, title, description, version, last_updated, owners, tags, status, stability, domain
Every image (![]()) must have descriptive alt text explaining the image's purpose, not its appearance. Empty alt (![ ]()) is valid only for purely decorative images
Link text must describe the destination — never use 'click here', 'read more', or bare URLs as visible text
Every table must have a header row (| Header |). Avoid merged cells
Use headings to communicate document structure, not for visual styling
Do not rely on colour alone to convey information in diagrams or callout blocks
Mermaid diagrams must includeaccTitleandaccDescrattributes for accessibility
Specify language in frontmatter; use plain language, avoid jargon where possibleDo not add a
referencesfrontmatter field to files; use inline links or footer sections instead
Files:
website/README.md
**/*.{css,html,js,php,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Follow WordPress Coding Standards (CSS, HTML, JavaScript, PHP) and inline-documentation standards at all times
Files:
website/src/styles/global.css
🔇 Additional comments (6)
website/astro.config.mjs (1)
1-5: LGTM!website/.gitignore (1)
1-3: LGTM!website/public/llms.txt (1)
1-22: LGTM!website/src/layouts/BaseLayout.astro (1)
1-48: LGTM!website/src/pages/index.astro (1)
1-68: LGTM!website/src/pages/references.astro (1)
1-51: LGTM!
🔍 Reviewer Summary for PR #755CI Status: ❌ Recommendations
|
Addressed in subsequent commits; stale review state no longer applies.
Summary
Implements the first executable slice of the
Awesome GitHubwebsite:website/llms.txtsupport and a faviconwebsite/**Testing
npm run buildinwebsite/website/README.mdfrontmatter withgray-matter.github/workflows/awesome-github-site.ymlwithyamlNotes
This is intentionally narrow: phase 1 only. Phase 2 can add search, richer browsing, and the fuller resource catalogue once this foundation is stable.