GitHub Pages Deployment Model
The repo's actual, sole deployment target: a GitHub Actions workflow builds the Jekyll site on every push to main and publishes it to GitHub Pages — with no Azure component, unlike the PRD's dual-target vision.
Estimated reading time: 2 minutes
Page Improvements
- Improve Page Polish content, structure, and presentation of this page
- Expand Page Add depth, examples, and missing sections to this page
- Update Page Refresh outdated content, versions, links, and screenshots
- Fix Page Issue Report a typo, broken link, layout glitch, or content bug
- SEO Optimize Improve discoverability, metadata, and structured data
- Accessibility Audit Audit this page for WCAG 2.1 AA compliance
Site Improvements
- UI/UX Improvement Propose a design or UX refinement for the theme
- New Feature Propose a new site-wide feature or capability
- Component Enhancement Improve a Jekyll layout, include, or shared component
- Performance Optimization Improve load time, Core Web Vitals, and asset delivery
Table of Contents
GitHub Pages Deployment Model
Definition
The mechanism by which this repository’s Jekyll site becomes a live website: on every push to main that touches pages/**, _config.yml, Gemfile*, or the workflow file itself, .github/workflows/pages.yml builds the site with Jekyll and deploys the result to GitHub Pages at https://bamr87.github.io/zer0-pages/ (baseurl: /zer0-pages).
How It Works
- A push to
maintriggers the Actions workflow. bundle installresolves thejekyll-theme-zer0gem (~> 1.25) and other Gemfile dependencies; CI runs on Ruby 3.3.jekyll buildruns, withpages/_plugins/(the bridge) converting wikilinks/Dataview/callouts to HTML and generating/assets/data/wiki-index.jsonfor the vault graph — see Jekyll/Obsidian Dual-Rendering Architecture.- The built
_siteis uploaded and deployed to GitHub Pages. - One-time manual prerequisite per repo: Settings → Pages → Build and deployment → Source: GitHub Actions — without this, the very first deploy fails with a
Get Pages site failed404.
There is exactly one deployment target. pages/.raw/ sources and wiki/ pages that reference other targets (see below) are describing a vision, not this pipeline.
Why It Matters
The zer0-pages PRD (§4 tech-stack table, §7.1, §11 launch criteria) frames deployment as a choice between “GitHub Pages, Azure, or any hosting platform,” implying a portable Django backend that could run anywhere. In reality, this repo has no backend to deploy elsewhere — it is a static site, and GitHub Pages is not one option among several but the only publishing mechanism that exists. That’s a meaningfully simpler (and cheaper — literally free) deployment story than the PRD implies, and it’s worth recording as ground truth so future ingestions don’t reintroduce an “Azure” deployment target that was never built.
Examples
- The PRD’s installation flow (§6.1) shows
curl … install.sh,pip install zer0-pages, anddocker-compose up -das user-facing setup paths — none of which exist in this repo; the only real “install” step for a contributor isbundle install(orbundle exec jekyll buildlocally) plus, for Obsidian authoring, openingpages/as a vault (see Getting Started with the Obsidian Vault). - The PRD’s §11 “Launch Criteria” checklist (“GitHub Pages deployment works with automatic CI/CD”) is the one launch criterion that is actually true of this repo today.
Connections
- zer0-pages — the repo/product this deployment model belongs to.
- Jekyll/Obsidian Dual-Rendering Architecture — the build-time process that produces what gets deployed.
- Graph view — one of the artifacts (
wiki-index.json+ the Cytoscape graph UI) produced during this same build and shipped as part of the deploy.
Sources
- zer0-pages PRD §4, §7.1, §11 — describes GitHub Pages as one of several targets; contrasted here with the single-target reality.
- Root
CLAUDE.md“Content flow” and “Build & test” sections — authoritative description of the actual pipeline.