Claude
cca652d71f
Builds on a push to main and deploys the result, so the thing is reachable without checking it out and running a dev server. Two details a project site needs that a root deployment does not: The base href is set from the repository name at build time. The app is served from a subdirectory there, and `DataLoaderService` fetches its catalogues with relative URLs — those resolve against `<base>` rather than the current path, so without it a deep link would ask for /body/assets/data/stars.bin. Pages serves a static tree with no rewrite rules, so /body/mars has no file behind it and returns 404. Answering that 404 with the app lets the router render the route. The status stays 404, which crawlers will notice and readers will not; the alternative is hash URLs, which everyone notices. Verified against a server that mimics both behaviours: the root loads the star field with all six catalogue assets at 200, and /body/mars boots through 404.html and renders Mars at 3,390 km with its assets still resolving. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G
71 lines
2.5 KiB
YAML
71 lines
2.5 KiB
YAML
name: Pages
|
|
|
|
# Publishes the built app to GitHub Pages. `main` only: `develop` is where work integrates and
|
|
# this is what the world sees, so a deploy should follow a promotion rather than every merge.
|
|
# `workflow_dispatch` covers the exception — dispatching from another ref publishes that ref.
|
|
on:
|
|
push:
|
|
branches: [main]
|
|
workflow_dispatch:
|
|
|
|
# One deployment at a time, and never cancel one in flight: a half-replaced site is worse than a
|
|
# slightly stale one. Queued runs supersede each other, so the newest commit still wins.
|
|
concurrency:
|
|
group: pages
|
|
cancel-in-progress: false
|
|
|
|
permissions:
|
|
contents: read
|
|
pages: write
|
|
# `deploy-pages` authenticates to the Pages service with an OIDC token rather than a secret.
|
|
id-token: write
|
|
|
|
jobs:
|
|
build:
|
|
name: Build the site
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v5
|
|
|
|
- uses: actions/setup-node@v5
|
|
with:
|
|
node-version: 22
|
|
cache: npm
|
|
|
|
- run: npm ci
|
|
|
|
# Enables Pages on first run if it is not on yet, and reports the URL the site will live at.
|
|
- uses: actions/configure-pages@v6
|
|
|
|
# A project site is served from a subdirectory, so the app cannot assume it sits at the
|
|
# root. The base href is what makes the router's URLs and the relative `fetch` calls in
|
|
# `DataLoaderService` resolve — those are written relative, so they follow `<base>` rather
|
|
# than the current path, and a deep link still finds `assets/data/*`.
|
|
#
|
|
# Derived from the repository name rather than written out, so a rename cannot leave a
|
|
# stale path here. A user/organisation site or a custom domain would want `/` instead.
|
|
- name: Build
|
|
run: npm run build -- --base-href "/${GITHUB_REPOSITORY#*/}/"
|
|
|
|
# Pages serves a static tree with no rewrite rules, so `/body/mars` has no file behind it
|
|
# and comes back 404. Answering that 404 with the app itself lets the router take over and
|
|
# render the route, which is the standard way to host a history-API app here. The status
|
|
# stays 404 — search engines notice, humans do not.
|
|
- name: Serve deep links through the app
|
|
run: cp dist/star-map/browser/index.html dist/star-map/browser/404.html
|
|
|
|
- uses: actions/upload-pages-artifact@v5
|
|
with:
|
|
path: dist/star-map/browser
|
|
|
|
deploy:
|
|
name: Deploy to Pages
|
|
needs: build
|
|
runs-on: ubuntu-latest
|
|
environment:
|
|
name: github-pages
|
|
url: ${{ steps.deployment.outputs.page_url }}
|
|
steps:
|
|
- id: deployment
|
|
uses: actions/deploy-pages@v5
|