Repository navigation
Prepare the move of the site to owaspacs.org - #416
Merged
Merged
Conversation
The site moves from the github.io project subpath to the apex domain. The deploy now writes CNAME into _site, and the site links, monitors, and project metadata name owaspacs.org. Schema $id values stay on github.io. The deploy's schema verify moves off page_url to the $id URIs, because verify_published.py requires a schema to serve the URL it was asked for, and on the custom domain page_url names a host no $id declares. It would have failed all 44 schemas on the first deploy after cutover. The schema monitor stays on github.io for the same reason and proves the 301 as it goes. The navigation monitor moves to the domain, because the verifier resolves links against the requested address and a redirect makes the rows differ. GitHub ignores CNAME on a site published by Actions, so the repository's Pages setting is what binds the domain. CLAUDE.md now says so. Part of #216 Signed-off-by: rocklambros <rock@rockcyber.com>
rocklambros
marked this pull request as ready for review
November 1, 2026 03:06
rocklambros
requested review from
GangGreenTemperTatum,
Lrd0036,
afogel,
almogbhl,
artmaro,
bar-capsule,
fewdisc,
mamicidal,
sclintonowasp and
stefanoamorelli
as code owners
November 1, 2026 03:06
Open
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
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.
What changed
Prepares the move of the ACS site from the github.io project subpath to the apex domain owaspacs.org. This merges only after DNS resolves and the domain is bound in the Pages setting. Do not merge it before then.
deploy-pages.ymlwritesCNAMEcontainingowaspacs.orginto_site, and its fallback URLs name the domain.README.md,SECURITY.md,project.owasp.yaml, andCLAUDE.mdfollow.$id,$ref, and the docs links to the schemas are untouched. They stay on github.io and follow the 301.Three things differ from what you might assume:
page_url.verify_published.pyrequires a schema to serve the URL it was asked for. After cutoverpage_urlis the domain, which no$iddeclares, so the first deploy would have failed all 44 schemas. It now checks the$idURIs, like the monitor does.CNAMEdoes not bind the domain. GitHub's docs say aCNAMEfile is ignored on a site published by a custom Actions workflow. The file is here as decided, but the Pages setting is what activates the domain, andCLAUDE.mdnow says that.mkdocs.ymlis unchanged.site_urlis!ENV GITHUB_PAGES_URL, tests pin that form, and the value comes fromconfigure-pages, which returns the domain once it is bound. Only the workflow fallback needed changing. The landing links and the CSP are relative or hash-only, so neither depends on the path.Which issue does this implement
Part of #216
meaning, so it needs no issue
Base branch
integration, because this touches the specification, schemas, a referenceimplementation, an adapter, tests, or CI
main, because every changed path is on the documentation lane allowlist inCONTRIBUTING.md
Type of change
Cutover sequence
Order matters. Binding the domain first means the promotion's deploy builds with the domain as its base.
https://owaspacs.org/loads. From here github.io 301s, so the 404 page's links and the navigation monitor are wrong until step 5, which should land the same day.integration.main, which redeploys.A red navigation verify on a green deploy can be a false red, per item 4 of the PR #366 review: a status under 500 is not retried, and the per-run nonce defeats the 404 retry. Fixing that changes behavior a test pins (
test_main_fails_a_wrong_status_without_retrying), so it is out of scope here. Re-running the workflow clears it.I tested this
uv run pytest -vpasses on my machineuv run mkdocs build --strictpasses on my machineuv run pytest -q: 1151 passed, 1 skipped.I built the site in deploy order with
GITHUB_PAGES_URL=https://owaspacs.org/docs/and ran the workflow's ownCNAMEcommand._site/CNAMEholdsowaspacs.org, and the sitemap and canonical URLs name the domain. The only github.io path left in the built pages is/schema/.Then I served that build from the root on a local stand-in, with a second stand-in issuing the github.io 301:
verify_published.pythrough the 301: 44 of 44.verify_published.pyat the domain: fails, as the commit explains.verify_site_nav.pyat the domain: ok.None of this ran on real Pages. The stand-ins used rebased
$idvalues over HTTP, so the real redirect and certificate are unproven until cutover.Checklist
git commit -s(required by the DCO)Security