feat(ci): guard against self-referencing frontmatter - #1070
Conversation
Add a CI check that fails when a file under hugo/content/ carries a github_repo pointing at gardener/documentation itself (self-reference) or combines local: true with github_repo. Both indicate local content wrongly tagged as aggregated, which makes the banner step classify it as read-only MANAGED. - post-processing/lib/selfref.js: detection logic + tests - post-processing/check-frontmatter.js: CLI scanning hugo/content - .github/workflows/check-frontmatter.yml: run on content PRs
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
✅ Deploy Preview for gardener-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks 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 |
Sitemap structure diff vs
|
| count | |
|---|---|
| ➕ added pages | 0 |
| ➖ removed pages | 0 |
First entries (full diff in the run summary & artifact):
ADDED (0):
(none)
REMOVED (0):
(none)
A rename appears as one removed (old path) + one added (new path).
How to categorize this PR?
/kind bug
/kind enhancement
What this PR does / why we need it:
This is a proposal for a CI check that prevents a class of frontmatter misclassification bug.
The problem: docforge aggregates upstream markdown into
hugo/content/and tags each file withgithub_repo. The banner step (post-processing/lib/banner.js->classify) treats any file withgithub_repoas MANAGED (read-only, overwritten nightly). Files without it are LOCAL (source of truth).A file whose
github_repopoints atgithub.com/gardener/documentationitself is a self-reference. Real upstream content never lives in the documentation repo, so such a value almost certainly means locally maintained content was accidentally tagged as aggregated. It then gets a MANAGED banner despite being the source of truth, and it is in no docforge manifest.Concrete example:
hugo/content/community/hackathons/2026-11.mdwas committed locally, then a later aggregation run injectedgithub_repo: 'https://github.com/gardener/documentation'. It ended up wrongly classified as MANAGED, and contradictorily carried bothlocal: trueand a MANAGED banner.What the check does:
post-processing/lib/selfref.js:isSelfReference()+findViolations(), flagginggithub_repopointing atgardener/documentation(self-reference)local: truecombined with anygithub_repo(contradictory)post-processing/check-frontmatter.js: scans every*.mdunderhugo/content/, uses the existinglib/frontmatter.jsread(), exits 1 on violations..github/workflows/check-frontmatter.yml: runs the check on content PRs (mirrorsenforce-managed-files.ymlstyle, pinned action SHAs).post-processing/lib/selfref.test.js(node:test, assert/strict) following the existinglib/*.test.jsstyle.Special notes for your reviewer:
2026-11.md(handled separately). Running the check onmastercurrently fails on exactly that file, which demonstrates it catches the real bug.node --test post-processing/lib/selfref.test.js-> 15/15 pass.