Skip to content

ci: deploy docs via Ddraig SSG#121

Merged
hyperpolymath merged 1 commit into
mainfrom
feat/ddraig-pages-mass
Jul 19, 2026
Merged

ci: deploy docs via Ddraig SSG#121
hyperpolymath merged 1 commit into
mainfrom
feat/ddraig-pages-mass

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Mass rollout for Ddraig SSG

@hyperpolymath
hyperpolymath merged commit ba29a18 into main Jul 19, 2026
1 check passed
@hyperpolymath
hyperpolymath deleted the feat/ddraig-pages-mass branch July 19, 2026 13:01
hyperpolymath added a commit that referenced this pull request Jul 21, 2026
…erge) (#128)

Follow-up to #123. This is the one commit from that branch that **missed
the merge** —
#123 was squash-merged at head `120f32d` (12:06 UTC); this commit was
authored at
12:17 UTC, ten minutes later, so it was never part of the PR and never
ran CI.

Main is red on `governance / Workflow security linter` today purely
because of it.

## What this fixes

`pages.yml` was dropped in by the Ddraig SSG mass-rollout (#121) without
this repo's
SPDX and SHA-pinning conventions. #123 fixed the missing SPDX header —
and that is
exactly what exposed this second defect: the linter `exit 1`s
immediately after its
SPDX/permissions block, so the pin check downstream had never been
reached.

```
ERROR: Found unpinned actions:
  .github/workflows/pages.yml:25  actions/checkout@v4
  .github/workflows/pages.yml:27  actions/checkout@v4
  .github/workflows/pages.yml:44  actions/upload-pages-artifact@v3
  .github/workflows/pages.yml:57  actions/deploy-pages@v4
```

The SHAs are **copied verbatim from `casket-pages.yml`** — the active,
already-compliant
Pages workflow in this repo — rather than freshly resolved, so the two
Pages workflows
converge on one vetted set instead of diverging into a third.

Side effect worth naming: this also moves `upload-pages-artifact` v3→v5
and
`deploy-pages` v4→v5, which is what makes them consistent with
`casket-pages.yml`.
`pages.yml` is `disabled_manually`, so there is **no runtime risk
today** — we are
unblocking a linter on a workflow that does not currently run.

## Verified locally (reproducing the linter's own grep)

```
PASS: all root actions SHA-pinned
(no root workflow missing an SPDX header)
all root workflows parse OK
```

## Expected CI on this PR — please read before judging the tick

`governance / Workflow security linter` → **should go green**.

`governance / Check Workflow Staleness` → **will stay red, by design.**
It is
independent of this change and was already failing on `main` before #123
existed. Its
three errors are all standards-reusable pin staleness (`d7c22711e830`,
59 commits / 24d
behind `8813ecf2a841`). That refresh is shared across ~54 callers and
coordinated
centrally, and there is a standing estate finding that consumers should
not be re-pinned
yet. Left to that effort deliberately.

**So the Governance *workflow* will still report failure on this PR.**
That is the
staleness job, not this fix. Do not read it as "the pin fix didn't work"
— check the
per-job conclusions.

Also settled while verifying: the staleness job's "Remove legacy
scorecard-enforcer.yml"
line is its **generic remediation summary**, printed on any failure —
not a path
detection. The only copy of that file is in the inert
`aletheia/.github/workflows/`, and
nothing is reaching into it. No action needed there.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant