perimeter/.github/workflows/pages.yml at main · ghzhost/perimeter · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
# Publish site/ to GitHub Pages, after checking the bytes that are about to be published
# rather than a rebuild of them.
#
# site/ is tracked in git and is built from CAL FIRE's acquired files, which are not in
# git and never in CI. So this workflow cannot regenerate site/ and diff it, the way a
# repository whose site renders from committed inputs would. What it does instead:
#
#   1. Builds from the committed fixtures twice and requires the two runs to be
#      byte-identical, which is the determinism claim the README makes, checked here as
#      well as in ci.yml.
#   2. Runs tests/test_published_site.py over the committed site/, which requires the
#      published artifacts to be a measurement of the real files rather than fixture
#      output, and requires the provenance they publish to still match the reviewed
#      constants in src/perimeter/sources.py. An acquisition that changes a version, a
#      byte count or a hash without a rebuild of site/ fails here.
#   3. Runs html-validate and axe-core over site/ itself, so the pages that get served
#      are the pages the WCAG gate passed, not a fixture build that resembles them.
#
# What none of that proves is that site/ is what the current pipeline would produce from
# CAL FIRE's files; only a machine holding those files can settle that, with `make site`
# and no diff. The tests say so in as many words rather than implying more.
#
# No network for data. Every input read here is committed. Every action is pinned to the
# full 40-char commit SHA of its tag, resolved 2026-08-07 via
# `gh api repos/OWNER/REPO/git/matching-refs/tags`, and kept as `@<sha> # vX.Y.Z` so the
# version stays readable next to the pin.
#
# Before the first deploy can succeed, Pages has to be told to take its source from this
# workflow: Settings > Pages > Build and deployment > Source > GitHub Actions.
name: publish-site

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions: {}

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

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0
        with:
          version: ">=0.11.0"
          python-version: "3.12"

      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
        with:
          node-version: "22"
          cache: npm

      - run: make sync

      # tools/determinism.sh, not an inlined pipeline. The version this replaces could not
      # fail: `find` on a missing directory exits 1, but under the default `bash -e` shell
      # without `pipefail` the pipeline reported xargs' status and the step stayed green,
      # and with no files to hash both sides came out identical, so an empty build passed.
      - name: the offline build must produce byte-identical output twice
        run: make determinism

      - name: the committed site/ must be a current measurement of the real files
        run: uv run pytest tests/test_published_site.py -q

      - run: make node-sync

      - name: the pages being published must pass the same HTML and WCAG gates
        run: |
          npx html-validate "site/*.html"
          node tools/a11y.mjs site

      - uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5.0.0

      - uses: actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9 # v5.0.0
        with:
          path: site

  deploy:
    needs: build
    runs-on: ubuntu-latest
    # The two scopes the Pages deployment API needs, on the one job that needs them. The
    # build job, which is the job that runs repository code, holds neither.
    permissions:
      pages: write # create the Pages deployment
      id-token: write # mint the OIDC token that deployment is authenticated with
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@cd2ce8fcbc39b97be8ca5fce6e763baed58fa128 # v5.0.0