Add Jekyll site structure and GitHub Pages deployment workflow#5
Add Jekyll site structure and GitHub Pages deployment workflow#5nduytg wants to merge 8 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR migrates the repository into a Jekyll-compatible structure and adds a GitHub Actions workflow to build and deploy the site to GitHub Pages, along with initial site scaffolding (layout, navigation, collections, and starter content).
Changes:
- Added Jekyll configuration for
docsandprojectscollections plus default layout behavior. - Introduced site scaffolding (default layout, navigation data) and top-level index pages for docs/projects/blog/about.
- Added a GitHub Actions workflow to build on PRs and deploy to GitHub Pages on pushes to
main, and removed theCNAMEto use the default Pages domain.
Reviewed changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/pages-deploy.yml |
Builds Jekyll and deploys to GitHub Pages on main pushes (also runs on PRs). |
_config.yml |
Defines site metadata, collections (docs, projects), permalinks, and default layout settings. |
_layouts/default.html |
Adds the default HTML layout and top navigation. |
_data/navigation.yml |
Defines the top navigation items used by the default layout. |
_docs/getting-started.md |
Adds a starter doc page in the docs collection. |
_projects/platform-engineering-case-study.md |
Adds a starter project/case-study template in the projects collection. |
_posts/2026-04-19-site-structure-update.md |
Adds an initial blog post announcing the structure update. |
index.md |
Adds the new homepage with links into the new content paths. |
cheat-sheets.md |
Adds a landing page that lists docs collection entries. |
projects.md |
Adds a landing page that lists projects collection entries. |
blog.md |
Adds a landing page that lists blog posts. |
about.md |
Adds an About page for the site. |
README.md |
Documents the new Jekyll content model, workflows, and Pages domain approach. |
CNAME |
Removed to stop using a custom domain. |
.pymarkdown.json |
Updates Markdown lint config to support Jekyll front matter. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| permissions: | ||
| contents: read | ||
| pages: write | ||
| id-token: write | ||
|
|
There was a problem hiding this comment.
Workflow-level permissions grant pages: write and id-token: write to the build job (including on pull_request), even though only the deploy job needs them. To follow least-privilege, move these permissions to the deploy job (and keep contents: read for build), or set job-level permissions so PR builds don't get write-level tokens unnecessarily.
| <header> | ||
| <h1><a href="{{ '/' | relative_url }}">{{ site.title }}</a></h1> | ||
| <p>{{ site.description }}</p> | ||
| <nav class="top-nav" aria-label="Top navigation"> | ||
| <ul> | ||
| {% for item in site.data.navigation %} | ||
| <li><a href="{{ item.url | relative_url }}">{{ item.title }}</a></li> | ||
| {% endfor %} | ||
| </ul> | ||
| </nav> | ||
| </header> | ||
|
|
||
| <main id="content" role="main"> | ||
| {{ content }} |
There was a problem hiding this comment.
The default layout renders an <h1> that always shows site.title, but it never renders page.title. Several new pages (e.g., about.md, blog.md) don't include an H1 in their Markdown, so the visible primary heading will be the same on every page, which hurts navigation/accessibility. Consider rendering page.title as the main heading (or providing a per-page heading slot) so each page has a unique top-level heading.
There was a problem hiding this comment.
Implemented in 93e2fb8: the layout now renders <h1>{{ page.title | default: site.title }}</h1> inside <main>, and the site title in the header is no longer the page H1.
Screenshot:
| concurrency: | ||
| group: pages | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
concurrency.group: pages applies to the whole workflow (including PR builds), so multiple pull requests will be forced to run sequentially and can queue behind each other and behind main deployments. If you only need serialization for deployments, consider moving concurrency to the deploy job or keying the group by ref for PR builds.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Agent-Logs-Url: https://github.com/nduytg/System-Engineer-Cheat-Sheets/sessions/ecf29689-6af8-4ea4-9da9-c682b79cbcc9 Co-authored-by: nduytg <12210776+nduytg@users.noreply.github.com>
Motivation
Description
/.github/workflows/pages-deploy.ymlto build the site with Jekyll and deploy to GitHub Pages on pushes tomainand to run the build on pull requests._config.ymlwithdocsandprojectscollections and default layouts for collections and posts._layouts/default.html,_data/navigation.yml,_docs/getting-started.md,_posts/2026-04-19-site-structure-update.md,_projects/platform-engineering-case-study.md, and top-level pagesindex.md,cheat-sheets.md,projects.md,blog.md, andabout.md.README.mdto document the new content model, CI/CD workflows, and the decision to use the default GitHub Pages domain; removed the repositoryCNAMEto disable the custom domain.Testing
Markdown lintworkflow which will run on pushes and pull requests, and the newBuild and Deploy GitHub Pagesworkflow will execute builds on PRs and deploy on pushes tomainwhen triggered by GitHub Actions.Codex Task