chore(ci): publish-docs.sh preserves docs-pages .github/#21
Merged
Conversation
The first run of deploy-docs.yml on main wiped \`.github/workflows/deploy-pages.yml\` from the docs-pages branch because PRESERVE only listed install.sh / install.sh.sha256 / CNAME. That workflow is what actually pushes pages to GitHub Pages on every docs-pages push — losing it broke the deploy chain silently (the docs-pages push reported success, but Pages stayed on the previous content because no workflow triggered). The deleted workflow has been manually restored on docs-pages via a direct API commit (which itself triggered the deploy and brought the site live). This commit ensures we don't redo the damage next time: - Add \`.github\` to the PRESERVE list (whole directory) - Switch stash/restore loops from \`cp -p\` to \`cp -a\` (preserves dirs + recurses; \`cp -p\` alone fails on directories) - Switch the restore guard from \`[[ -f ]]\` to \`[[ -e ]]\` so it matches directories as well as regular files Verified by reading the deploy-docs run log of the broken deploy (commit 1ef5540 on docs-pages): the 55-file commit included "delete mode 100644 .github/workflows/deploy-pages.yml". After the manual restore (commit 22f3088 on docs-pages), the Pages deploy ran and stint.reyem.tech now serves the full Starlight site. Filed as chore(ci) rather than fix because the shipped app is unchanged — this is purely a deploy-script fix. No version bump warranted; users wouldn't see any difference if we cut v0.2.1.
mariomeyer
force-pushed
the
fix-publish-docs-preserve-github
branch
from
2f94e16 to
aeb4f2b
Compare
mariomeyer
changed the title
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.
What broke
The first run of `deploy-docs.yml` (after PR #20 merged) wiped `.github/workflows/deploy-pages.yml` from the `docs-pages` branch. That workflow is what triggers GitHub Pages deploys on every `docs-pages` push. Losing it broke the deploy chain silently — the docs-pages push reported success, but Pages stayed on the previous content because no workflow triggered after.
Discovered via `curl https://stint.reyem.tech/help/privacy/\` returning 404 after the merge. The page existed on the docs-pages branch (verified in the deploy run log), but Pages was serving the pre-Phase-5 stub.
What's fixed live
```
privacy: 200
install: 200
install.sh: 200
quickstart: 200
license: 200
cli: 200
```
What this PR fixes (prevents recurrence)
`scripts/release/publish-docs.sh`:
After this lands, the next deploy-docs run will leave `.github/` alone on docs-pages instead of wiping it.
Test plan
Merge via "Create a merge commit" per standard. This is a `fix:` so it'll trigger a v0.2.1 release — that's the right outcome (the deploy regression was a real user-impacting bug; cutting a patch documents the fix in CHANGELOG).