Repository navigation
ci: squash gh-pages history on every release - #15743
Merged
Merged
Conversation
Each deploy commits a full set of rebuilt PDF and ePub files, so gh-pages grows by ~18 MiB a day and is now 3.5 GiB of the repository's 3.7 GB. On each final release tag, rebuild gh-pages as one snapshot commit per release day, keep the deploys made since the last release, and store out-of-support version folders only once. The tip tree is unchanged and the rewrite is deterministic, so re-running it is a no-op. Assisted-by: ClaudeCode Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
skjnldsv
force-pushed
the
feature/squash-gh-pages-history
branch
from
October 8, 2026 13:13
298c2eb to
706ca9e
Compare
Contributor
📖 Documentation PreviewNo RST documentation pages changed in this PR. Last updated: Thu, 08 Oct 2026 13:46:10 GMT |
susnux
approved these changes
Oct 8, 2026
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.
gh-pages is 3.54 GiB of the repository's 3.7 GB and grows by about 18 MiB a day, because every deploy commits a full set of rebuilt PDF and ePub files. Switching to the daily deploy in May lowered the number of commits, but not the growth (17.8 MiB/day per push, 16.2 daily per version, 18.0 daily single PR).
This adds a workflow that runs on each final release tag and rewrites gh-pages as:
build/detect-versions.php, so 12 to 32 today) stored once, with their current content.The published tree is unchanged, and the script checks that before pushing. Running it again on its own output changes nothing, so several tags pushed on the same day are fine.
Measured on a full clone of the current gh-pages: 347 commits down to 20, 3621 MiB down to 852 MiB packed. After that, growth should be roughly 25 to 30 MiB per release, plus the unreleased deploys until the next release squashes them.
Important
The "Pages" ruleset blocks force pushes to gh-pages and only lets org admins bypass it. Before this can run, an admin has to create a deploy key with write access, add it as a bypass actor on that ruleset, and store its private key as the
GH_PAGES_DEPLOY_KEYsecret.☑️ Resolves
🖼️ Screenshots
No visual change, CI only.
✅ Checklist
codespellor similar and addressed any spelling issuesTested with the 9 unit tests in
build/testsand by running the script on a full local clone of gh-pages. I have not run the workflow on GitHub, the force push and the PR closing step are untested.👾 This pull request was assisted by Claude Code, commits carry an
Assisted-bytrailer.