ci: refresh the site's download and star counts daily - #397
Open
caezium wants to merge 1 commit into
Open
Conversation
The landing page's "Already downloaded by N people" line and the star counts in every page's nav are baked into docs/stats.json when site-release.py runs, so they freeze the moment nobody runs it by hand. They were last written on 2026-08-08 and had sat at 13,091 downloads while the real total passed 24,000 — the README's shields.io badge, which sums the same per-asset download counts, was live the whole time. Add a daily workflow that runs `site-release.py --stats`, commits only when the numbers move, and dispatches the site deploy. The dispatch is explicit because a push made with GITHUB_TOKEN deliberately does not start other workflows, so deploy-site.yml's docs/** path filter would never fire on the bot's own commit; workflow_dispatch is the documented exception to that rule. gh_json() now sends GH_TOKEN when it is set. Anonymous GitHub API access is 60 requests/hour per source IP and Actions runners share IPs with the whole fleet, so the scheduled refresh would 403 at random without it. Also apply one refresh now, so the site is correct before the first scheduled run rather than a day after it.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (20)
Included review availability: Your plan includes up to 3 reviews per rolling hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe pull request adds authenticated GitHub statistics retrieval and a scheduled or manual workflow that commits changed statistics and triggers deployment. It updates repository star and download counts in the statistics file and generated site pages. ChangesSite statistics refresh
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change automates daily refreshes of the site's download and star counts and updates the site with current values; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
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.
Why
The landing page's "Already downloaded by N people" line and the star count in every page's nav are baked into
docs/stats.jsonwhensite-release.pyruns, so they freeze the moment nobody runs it by hand. That file had exactly one commit — 2026-08-08 — and had been reading 13,091 downloads / 1,214 stars ever since, while the real totals reached 24,358 / 1,279.The README badge never had this problem: shields.io re-renders it per view from the same per-asset download sum. Only the site was stale.
What
.github/workflows/refresh-stats.yml— daily at 07:41 UTC (clear of the upstream watcher's 08:17), plus manual dispatch. Runssite-release.py --stats, commits only when the numbers move, then dispatches the site deploy.gh_json()now sendsGH_TOKEN/GITHUB_TOKENwhen set.Two things worth a look in review
The deploy is dispatched explicitly, not left to the path filter. A push made with
GITHUB_TOKENdeliberately does not start other workflows, sodeploy-site.yml'sdocs/**trigger would never fire on the bot's own commit.workflow_dispatchis the documented exception to that recursion guard, hence the extra step andactions: write.The token is not optional. Anonymous GitHub API access is 60 requests/hour per source IP, and Actions runners share IPs across the whole fleet, so an unauthenticated scheduled refresh 403s at random.
Verification
Both API paths exercised locally (authenticated and anonymous) — same totals. The regeneration touched only count lines across 17 pages, with no unrelated drift, which also confirms main's generated tree is currently in sync.
The workflow itself is untested end-to-end, since scheduled runs only fire from the default branch. After merge:
Conflict note
#392 generates the site in ten languages, which multiplies the pages carrying these counts. The workflow is agnostic — it regenerates whatever the generator emits — but the
docs/half of this diff will likely conflict with that branch. Whichever merges second just needs a regeneration.Summary by CodeRabbit
New Features
Documentation
Bug Fixes