Repository navigation
Strip out hugo ported theme to standalone repo - #72
Merged
scriptautomate-bc merged 18 commits intoAug 21, 2026
Merged
scriptautomate-bc merged 18 commits into
scriptautomate-bc merged 18 commits into
Conversation
Go here is only used to resolve the pydata-hugo-theme Hugo Module (no .go source files live in this repo), so this is a version-floor bump, not a behavior change. Verified: re-vendoring with the real Go 1.27.0 toolchain produced a byte-identical _vendor/ tree and an unchanged Hugo build (169 pages).
Replace the classic vendored theme dir (themes/pydata) with a proper Hugo Module import, resolved locally via sandbox/pydata-hugo-theme and vendored into _vendor/ so the site still builds with no Go toolchain or network access needed.
The site-level layouts/page.html override that rendered .Title as an <h1> is now a native, opt-out theme feature (show_title param), so it no longer needs a project-level override.
event-calendar and working-groups no longer need dedicated page layouts; their embeds are now shortcodes invoked from regular content pages, using the theme's default page template.
FontAwesome/Bootstrap build output now ships pre-built in _vendor/, so CI no longer needs Node.js or npm ci to build the site.
Runs weekly and on-demand, re-vendors via scripts/update-vendored-theme.sh, and opens a PR if anything changed. Never auto-merges -- vendoring the theme is a deliberate, human-reviewed action.
The theme's build-time JS deps are now checked into _vendor/, so the devcontainer no longer needs to install Node.js/npm.
Picks up the theme-side fixes for subpath home links, broken icon glyphs, search under a subpath, and the new copy-to-clipboard code block feature. Re-copies LICENSE/README.md, which hugo mod vendor always skips.
Removes the local `replace => ./sandbox/pydata-hugo-theme` directive now that the module is genuinely published (v0.2.0 tag resolves via the Go module proxy and checksum database). Bumps the require to v0.2.0, adds go.sum with the real verified checksum, and re-vendors against the network-resolved module. Confirmed the build is unaffected: hugo --minify still produces 169 pages, and the vendored tree only differs by the version bump and a README link addition from the theme's own v0.1.0->v0.2.0 changes -- no unexpected drift.
…eme.sh
go list -m -f '{{.Dir}}' needs the module in Go's own module cache,
which hugo mod get/vendor's internal client doesn't necessarily
populate -- the script silently produced an empty directory and
failed to copy LICENSE/README.md ("cp: cannot stat '/LICENSE'").
Only surfaced now that this actually got exercised against a real
published module for the first time.
The previous fix (go mod download + go list -m) resolved the wrong copy of the module: Hugo maintains its own separate module cache from Go's, so npm-installing into Go's copy did nothing for `hugo mod vendor`, which reads from Hugo's cache instead. Vendoring a version for the first time (cold cache) failed every time trying to find node_modules/@fortawesome/... -- confirmed by testing against a genuinely fresh HUGO_CACHEDIR, which is exactly the situation every run of the scheduled check-theme-updates.yml workflow is in. Resolve the version Hugo actually pinned via `hugo mod graph`, compute Hugo's own on-disk cache path for it, and npm ci the theme's build-time deps there before vendoring. Also add the Node.js install step check-theme-updates.yml was missing entirely. Verified end to end against a cold cache in a throwaway clone.
Picks up the theme's new footer credit line ("Built with the PyData
Hugo Theme", linking to the theme's own docs instead of upstream's)
and the theme_version_text override param.
Confirmed hugo --minify still produces 169 pages, and the vendored
tree only differs by the version bump and the footer partial change
-- no unexpected drift.
scriptautomate-bc
changed the title
hugo mod get/tidy don't prune go.sum the way a plain `go mod tidy` does for a normal buildable module -- old versions' checksums just accumulate across bumps. Removed the v0.2.0 entries now that go.mod only requires v0.3.0. (Note: this repo has no .go source files, so a bare `go mod tidy` isn't safe to run here -- it tries to resolve importable Go packages across the whole tree instead of just tidying go.sum. Pruned by hand instead.)
hugo mod get/vendor don't prune go.sum across version bumps -- old versions' checksums just accumulate (confirmed: v0.2.0's two lines were still sitting in go.sum after bumping to v0.3.0, only caught by manual inspection). A plain `go mod tidy` isn't safe here since this repo has no .go source files, so it tries to resolve importable Go packages across the whole tree instead of just tidying go.sum. Drop any go.sum line for this module that doesn't match the version just resolved. Verified in a throwaway clone with a simulated stale entry: the fake old version got pruned, the real one survived, and the site still builds correctly against the pruned file.
Picks up the new per-page show_prev_next frontmatter override, which we're about to use on the Event Calendar, Working Groups, and RSS Feeds pages to drop their prev/next footer links (those pages don't have a meaningful "previous/next page in section" relationship). Confirmed hugo --minify still produces 169 pages, and go.sum only contains v0.4.0 checksums (the script's self-pruning fix held).
Event Calendar, Working Groups, and RSS Feeds aren't part of a meaningful "previous/next page in section" sequence, so the prev/next footer links there were pointing at unrelated pages. Uses the new per-page show_prev_next frontmatter override from pydata-hugo-theme v0.4.0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Migrates the site from a classic vendored theme dir (
themes/pydata) to consumingpydata-hugo-themeas a real, published Hugo Module, plus a handful of related content/CI/devcontainer cleanups that fall out of that migration. This is primarily an infrastructure migration — verified byte-for-byte compatible with the prior classic-theme build, with one deliberate, small visual exception called out below (the footer credit line).The theme now lives in its own repo, is tagged/released independently (currently
v0.3.0), and resolves for real via the Go module proxy — there is no localreplacedirective in this branch;go.mod/go.sumpin a genuine network-resolved version.What changed
themes/pydata→ consumed as a Hugo Module (github.com/saltstack/pydata-hugo-theme v0.3.0, resolved from the real published module, not a local checkout), vendored into_vendor/github.com/saltstack/pydata-hugo-theme/so the site still builds with no Go toolchain or network access needed at build time (hugo --minifyalone, same as before).layouts/page.htmloverride that auto-rendered.Titleas an<h1>is now a native, opt-out theme feature (show_titleparam), so the site no longer needs to carry that override itself.event-calendarandworking-groupsno longer need dedicated page layouts; they're now shortcodes invoked from regular content pages using the theme's default page template.npm cisteps ingh-pages.yml/pr-checks.yml(the theme's build-time JS deps ship pre-built in the vendored tree now), and added a scheduled workflow (check-theme-updates.yml) that checks weekly for theme module updates, re-vendors viascripts/update-vendored-theme.sh, and opens a PR — never auto-merges, since vendoring is meant to be a deliberate, human-reviewed action.scripts/update-vendored-theme.sh: bumps/pins the module version, re-vendors, and re-copiesLICENSE/README.md(whichhugo mod vendorskips). Also handles a real gotcha specific to vendoring a version for the first time on a cold cache (any CI runner, always cold): the theme mounts build-time npm deps (FontAwesome/Bootstrap) via[[module.mounts]], and vendoring needs those installed into Hugo's own on-disk module-cache copy — a different location from both this repo's and Go's own caches — beforehugo mod vendorcan find them. Verified end to end against a genuinely coldHUGO_CACHEDIRin a throwaway clone, not just re-run against an already-warm cache.check-theme-updates.ymlinstalls Node.js itself for that one job).0.165.0.theme_version_textparam, if we ever want to change it without another theme bump.Verification
hugo --minifybuilds cleanly (169 pages, no errors/warnings) against the real publishedv0.3.0module.v0.3.0to confirm it's fully in sync.scripts/update-vendored-theme.shwas independently tested against a fresh clone with a cold Hugo module cache to confirm the re-vendor path works from a clean state, not just an already-warm one — this is what surfaced (and let us fix) the npm-mount cold-cache gotcha above.Not in this PR
v0.3.0and resolves via the real Go module proxy/checksum database), and this branch already consumes it for real rather than via a localreplace.docs/content/get-started/install.md), not here, since it applies to any consumer vendoring that theme, not just this one.