Skip to content

Instantly share code, notes, and snippets.

@nishio
Last active May 28, 2026 04:27
Show Gist options
  • Select an option

  • Save nishio/35d604f23a39aca369ac74db8b65b655 to your computer and use it in GitHub Desktop.

Select an option

Save nishio/35d604f23a39aca369ac74db8b65b655 to your computer and use it in GitHub Desktop.
Quartz + GitHub Pages project site hosting design memo

Quartz + GitHub Pages project site で Wiki を公開する設計メモ

Quartz で Obsidian 風 Wiki を GitHub Pages に公開する時、https://<user>.github.io/<repo>/ のような project site 配信では「subdir 対応」をまず疑うことになる。しかし、ここで HTML の <base> や redirect script を足すのは筋が悪い。

結論は次の 3 点。

  1. GitHub Pages project site は Quartz の configuration.baseUrl で扱う
  2. wiki/ を直接 Quartz に読ませるか、wiki/ -> content/ に変換するかは別問題として選ぶ
  3. subdir で壊れやすい index / search / explorer / assets は、生成後の public/ を CI で検査する

このメモは、古い「wiki/ -> content/ 変換前提」の手順を否定するものではない。あれは汎用 Obsidian vault を公開用に整形するには有効。ただし、Quartz 本体が project site hosting に未対応だから変換や <base> patch が必要、という理解は誤り。

まず押さえること

Quartz 4 の GitHub Pages 対応では、baseUrl に subpath まで含める。

const config: QuartzConfig = {
  configuration: {
    pageTitle: "My Wiki",
    baseUrl: "nishio.github.io/kouchou-ai-developer-wiki",
    locale: "ja-JP",
    // ...
  },
}

重要な形式:

  • https:// は書かない
  • 末尾 / は書かない
  • project site なら <user>.github.io/<repo> まで書く
  • user / org site なら <user>.github.io だけを書く

<base href="..."> は入れない。<base> はページ内の相対 URL 解決をブラウザレベルで変えてしまうため、Quartz が出す相対リンク、SPA 遷移、search index の fetch()、Explorer のリンク、asset path の前提と衝突しやすい。root URL の末尾 slash 欠落も、通常 GitHub Pages 側が /repo から /repo/ へ redirect するので、Quartz の Head を patch して補正する理由は弱い。

2 つの方式

方式 A: wiki/ を Quartz に直接読ませる

この repo の wiki/ が公開対象そのもので、LLM や人間が編集する source of truth でもあるなら、こちらを第一候補にする。

{
  "scripts": {
    "build": "quartz build -d wiki",
    "check:pages-links": "python3 scripts/check_pages_links.py"
  }
}

利点:

  • source of truth が wiki/ から分裂しない
  • content/ の自動生成差分をレビューしなくてよい
  • Quartz の -d / --directory があるので構成が単純
  • wiki/index.txt や独自 lint など、LLM 向け運用と衝突しにくい

向いている条件:

  • wiki/ 全体が公開可能
  • Quartz が読める Markdown に寄せられる
  • wikilink のファイル名重複や frontmatter を自前 lint で管理できる
  • private/public の分離が不要

方式 B: wiki/ -> content/ に変換してから Quartz に読ませる

汎用 Obsidian vault や、公開前に整形が必要な Wiki ならこちらが向く。

wiki/                   # 編集用
  -> scripts/resolve-links.py
content/                # Quartz 入力用、自動生成または準生成
  -> quartz build
public/                 # HTML 出力

利点:

  • [[ページ名]][[path/to/page|ページ名]] に正規化できる
  • title / aliases から独自の link map を作れる
  • private ページや Obsidian 固有ファイルを公開前に除外しやすい
  • Quartz に渡す Markdown を安定した形にできる

向いている条件:

  • Obsidian vault と公開サイトの構造を分けたい
  • private / draft / attachment の扱いが複雑
  • ファイル名重複や alias 解決を編集時ではなく build 時に吸収したい
  • Quartz に直接読ませると壊れる記法が多い

選び方

条件 推奨
Wiki がこの repo の公開 source of truth 方式 A
LLM が wiki/ を直接編集し、同じ tree を lint している 方式 A
Obsidian vault から公開可能な一部だけ出したい 方式 B
private notes / attachments / aliases が多い 方式 B
変換後 Markdown もレビュー対象にしたい 方式 B
生成物の drift を増やしたくない 方式 A

今回の kouchou-ai-developer-wiki では方式 A が自然。wiki/ がすでに LLM 向けの source of truth で、index.txtlog.txt、frontmatter lint、wikilink lint も wiki/ を直接見ている。ここで content/ を足すと、公開のためだけに第二の source tree が生まれる。

一方、以前の Gist のような「任意の Obsidian Wiki を Quartz + GitHub Pages に載せる」用途では方式 B が自然。公開前の正規化層があった方が運用しやすいから。

GitHub Actions の形

方式 A の最小形は次のようになる。

name: Deploy Wiki to GitHub Pages

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: pages
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup pnpm
        uses: pnpm/action-setup@v4
        with:
          version: 10.18.2

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "pnpm"

      - name: Install dependencies
        run: pnpm install --frozen-lockfile

      - name: Configure GitHub Pages
        uses: actions/configure-pages@v5

      - name: Build site
        run: pnpm build

      - name: Check generated links
        run: pnpm check:pages-links

      - name: Upload Pages artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: public

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

fetch-depth: 0 は、Quartz の CreatedModifiedDate({ priority: ["frontmatter", "git", "filesystem"] }) のように git 履歴を見る設定なら入れる。shallow clone だと CI 上の日付が不自然になりやすい。

生成物リンク検査を入れる

subdir のリンク切れは、Markdown lint だけでは検出しにくい。Quartz が生成した HTML、search index の fetch()、CSS/JS asset、Explorer 由来のリンクを、GitHub Pages project site と同じ base path で解決して検査するのがよい。

検査したいこと:

  • 生成 HTML に <base> が入っていない
  • 内部リンクが /repo/ の外へ逃げていない
  • href, src, srcset, poster が存在する public/ path に解決される
  • inline script の fetch("...") が search index などに届く

同梱の check_pages_links.py はこの用途の最小スクリプト。quartz.config.tsbaseUrl を読み、public/ 配下の HTML を全部検査する。

pnpm build
python3 scripts/check_pages_links.py

通ると次のような出力になる。

Pages link check passed: 4878 internal refs under /kouchou-ai-developer-wiki/

トラブルシューティング

CSS や内部リンクが 404

まず quartz.config.tsbaseUrl を見る。https:// や末尾 / が入っていないか、repo 名まで含んでいるかを確認する。

top page は見えるが index / search / explorer が壊れる

HTML の <base> patch や独自 redirect を疑う。Quartz upstream の構造に戻し、生成物リンク検査を入れる。

GitHub Pages の source 設定で迷う

Settings -> Pages -> Build and deployment -> Source は GitHub Actions にする。gh-pages branch や docs/ branch 配信ではなく、Actions が public/ artifact を upload する形に寄せる。

全ページの日付が同じ、または CI だけ日付が変

actions/checkoutfetch-depth: 0 を入れる。Quartz が git log を読めないと filesystem time に落ちやすい。

wikilink が壊れる

方式 A なら source 側の lint を強くする。ファイル名重複、frontmatter の YAML parse、未解決 wikilink、index catalog の未登録を検査する。

方式 B なら resolve-links.py の link map と broken link 出力を見る。title / aliases の衝突もここで検出する。

参考

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment