feat: bring the landing page into the repo and deploy it from CI - #6
Merged
Conversation
The page was hosted on Netlify and lived in no repository at all. When that host was retired the files were recovered from the deployment; this puts them under source control next to the toolkit they advertise. deploy-site.yml is separate from ci.yml because the PowerShell gate has nothing to say about HTML, and it is path-filtered so toolkit commits do not redeploy the page. Its one check is that every local asset index.html references actually exists — a missing stylesheet is a silent 404 in production rather than a build error.
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.
The landing page at tweakeazy.pages.dev was hosted on Netlify and lived in no repository at all. When that host was retired the files were recovered from the deployment itself. This puts them under source control, next to the toolkit they advertise.
What's here
site/— the page as recovered: hand-written HTML/CSS/JS, no build step, no dependencies. What's in the folder is exactly what gets served.site/_headers— cache and security headers, reconstructed from the response headers the live site was actually serving (the old host config was not retrievable through its API)..github/workflows/deploy-site.yml— publishessite/to the Cloudflare Pages projecttweakeazyon a push tomain.Why a second workflow
ci.ymlis PSScriptAnalyzer and Pester. It has nothing to say about HTML, and running the PowerShell gate on a CSS change would be noise.deploy-site.ymlis path-filtered tosite/**, so toolkit commits don't redeploy the page and page commits don't wait on the Windows matrix.It does not touch the existing gate: PSScriptAnalyzer only reads PowerShell files, and the Pester coverage globs only match numbered phase directories (
^\d+), sosite/is invisible to both.The one check it runs
Nothing compiles, so the only thing worth proving before a deploy is that every local asset
index.htmlreferences actually exists. A missing stylesheet is a silent 404 in production, not a build error.Verified both directions:
script.jsmoved aside →::error::on that line, exit 1Note on the deploy step
--branch=mainis what marks the upload as production. Without it Pages files every deploy as a preview — which succeeds, prints a URL, and never moves the live site.If
CLOUDFLARE_API_TOKENis missing the run stays green and logs a warning rather than failing, so the repo still works for anyone forking it without the secrets.CLOUDFLARE_ACCOUNT_IDis already set.