build(hugo): let newer Hugo versions build the site at all - #638
build(hugo): let newer Hugo versions build the site at all#638Timur Tukaev (tym83) wants to merge 1 commit into
Conversation
Hugo's default content policy is `! ^text/html$` — everything except HTML — so from 0.161 onwards an .html file is refused as a page source. This site's landing pages are exactly that, content/<lang>/_index.html in all five locales, so any build on a newer Hugo dies on the first one it reaches with access denied: "text/html" is not whitelisted in policy "security.allowContent" before rendering a single page, and the message never mentions a version. Anyone whose system Hugo is newer than the pin cannot run `hugo server` or a plain `hugo` build on this repo — which is a poor first encounter for a contributor arriving to fix a typo. Allow every content type back. Not narrowed to '^text/html$' deliberately: allowContent is an allowlist, so that value permits HTML and nothing else, and every markdown page fails instead. The pin stays at 0.160.1 and CI is untouched. A production build (`hugo --gc --minify`) on 0.161+ hits a second, unrelated wall: Hugo runs PostCSS under Node's permission model with allowRead defaulting to the project directory, while Docsy's SCSS is read from the module cache outside it, so the transform fails with "Access to this API has been restricted". Neither security.node.permissions.allowRead (the config does not expand $HOME or $HUGO_CACHEDIR) nor an in-project cacheDir cleared it. Bumping the pin therefore needs that solved first, and is left for its own change; the comment in hugo.yaml records where the next person should start. Verified: 0.160.1 and 0.164.0 both build in dev/preview mode with this config, and the pinned 0.160.1 production build is unchanged — same 2592 pages, no errors. Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Closing as redundant — this landed in #636 ( For the record, since this PR's description claims otherwise: The one thing worth carrying forward: the error a contributor sees on a newer Hugo says nothing about which version to install. Worth a line in CONTRIBUTING.md if anyone touches it. |
1 participant
Summary
Anyone whose system Hugo is newer than the 0.160.1 pin cannot build this repo at all — not
hugo server, not a plainhugobuild. The failure is a wall of security-policy output that never mentions a version, so the natural conclusion is that the repo is broken rather than that a specific Hugo is required.What
One config block. Hugo's default content policy is
! ^text/html$— everything except HTML — so from 0.161 onwards an.htmlfile is refused as a page source. This site's landing pages are exactly that,content/<lang>/_index.htmlin all five locales, so the build dies on the first one it reaches:security.allowContent: ['.*']restores it. Deliberately not narrowed to'^text/html$': the list is an allowlist, so that value would permit HTML and nothing else, and every markdown page would fail instead. That trap is written into the comment so the next person does not try it.What this PR does not do
The pin stays at 0.160.1 and CI is untouched. I tried to bump it and backed out: a production build (
hugo --gc --minify) on 0.161+ hits a second, unrelated wall. Hugo now runs PostCSS under Node's permission model withallowReaddefaulting to the project directory, while Docsy's SCSS is read from the module cache outside it, so the transform fails withAccess to this API has been restricted. Neithersecurity.node.permissions.allowRead(the config does not expand$HOMEor$HUGO_CACHEDIR) nor an in-projectcacheDircleared it — the latter fails config validation outright. Bumping the pin needs that solved first and deserves its own PR; the comment inhugo.yamlrecords where to start.So after this change: dev and preview work on any version, production still needs 0.160.1. That is strictly better than today, where nothing works on a newer version.
Verification
hugo server/ plain build: passes on both 0.160.1 and 0.164.0.hugo --gc --minifyon 0.160.1): passes, 2592 pages, no errors — unchanged.headmeta block, which Hugo's internalopengraphandtwitter_cardstemplates now write with tabs.module.mounts.lang,.Site.Data,.Language.LanguageName,.Language.LanguageDirection, plus thelanguageCode/languageNameconfig keys) are not affected by this change — 0.160.1 emits them too.mounts.lang→sites.matrixtouches the multilingual mount setup for five locales and is its own piece of work.