docs: make the donation ask findable, add contributors and a star chart - #155
Conversation
The addresses were technically present and practically invisible — a line at
the very bottom of the README pointing at DONATE.md. Anyone who wanted to
support the project had to go looking for how.
Now: a donate badge in the header row, and a centred block directly under
Install, which is where people are when they've just decided they like it.
Same block on the landing page, boxed in the accent colour, with a Donate
link in the site nav. Same content, just findable.
Adds a contributors section (contrib.rocks) that credits the people who
made it better — mostly by wearing it on a real wrist and reporting what
came out wrong, which is worth saying out loud given there is one person's
physiology in the test data.
Star chart is SELF-HOSTED, and that is deliberate rather than
not-invented-here:
* star-history.com refuses these repos outright — it answers "GitHub
restricted starred-data access for openstrap/edge".
* starchart.cc rate-limits anonymous callers, so the image renders as a
broken graphic some of the time.
* Both would have every visitor's browser call a third party. GitHub
proxies README images through camo, so that would not leak there, but
the landing page has no such protection, and a page arguing your data
stays on your device should not be quietly making outside requests.
So tool/gen_star_history.py pulls the stargazer timestamps and emits a plain
SVG — no script, no external reference, theme-aware for light and dark — and
a weekly workflow regenerates it and commits only when it changed. The
chart shows all three repos and makes the Hackaday/Adafruit spike obvious,
which is a more honest picture of where this actually stands than a star
count on its own.
Also added downloads and stars badges. There is no such thing as a GitHub
trending badge — GitHub exposes no API for it — so those plus the chart are
the closest honest equivalent.
Note the star-history workflow needs `contents: write` to commit the
regenerated file. That is a deliberate exception to the read-only default on
the test workflow, scoped to this one job.
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughChangesThe pull request adds a star-history SVG generator and weekly/manual GitHub Actions refresh workflow, then integrates the generated chart and expanded donation content into the README and documentation landing page. Star history and donations
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant Generator
participant GitHubAPI
participant Repository
GitHubActions->>Generator: run tool/gen_star_history.py
Generator->>GitHubAPI: request paginated star timestamps
GitHubAPI-->>Generator: return stargazer data
Generator->>Repository: write docs/star-history.svg
GitHubActions->>Repository: commit and push when SVG changes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
PR Reviewer Guide 🔍(Review updated until commit 00b0e28)Here are some key observations to aid the review process:
|
PR Code Suggestions ✨No code suggestions found for the PR. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tool/gen_star_history.py`:
- Around line 140-142: Update the output generation near the stamp construction
and SVG text append so unchanged star data produces identical output across
runs: remove the current-date “updated” stamp, or derive it from the latest
stargazer timestamp instead of datetime.now(timezone.utc). Preserve the existing
SVG formatting and use the star data’s latest timestamp when retaining the
label.
- Around line 150-154: Update the repository-processing flow around
stargazer_dates so a RuntimeError aborts the entire chart generation instead of
continuing to publish a partial result. Preserve the warning output, then
propagate or otherwise terminate generation before docs/star-history.svg is
overwritten or committed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 22748353-c67f-4169-b9d9-817ed3766d83
⛔ Files ignored due to path filters (1)
docs/star-history.svgis excluded by!**/*.svg
📒 Files selected for processing (5)
.github/workflows/star-history.ymlREADME.mddocs/index.htmldocs/style.csstool/gen_star_history.py
Two CodeRabbit findings on the generator, both correct. The chart stamped datetime.now(), which changed the SVG on every run. That made the workflow's `git diff --quiet` no-change path unreachable, so it would have committed a pointless revision every Monday forever — the exact churn that guard exists to prevent. The stamp now comes from the most recent star, so the file is byte-identical until a star actually arrives, which is precisely when a commit is warranted. Verified: two consecutive runs now produce identical bytes. Second, a failed fetch for one repo was logged and skipped, then the partial chart was written and committed over the last good one — a transient API blip would silently drop a series from the published chart. Now aborts instead, leaving the previous complete chart in place until the next run.
Both CodeRabbit findings applied — the first was a real bug in the workflow1. The chart wasn't deterministic, which defeated its own no-change guard. I stamped Stamp now derives from the most recent star, so the file is byte-identical until a star actually arrives — which is precisely when a commit is warranted. Verified: 2. A partial chart could overwrite a good one. A failed fetch for one repo was logged and skipped, then the incomplete chart was written and committed over the last good version — so a transient API blip would silently drop a series from the published chart, with no signal that it had happened. Now aborts instead, leaving the previous complete chart in place until the next run. Fail-closed is right here: a missing week is recoverable, a silently-degraded published artefact isn't. Confirmed no imports became unused after removing the wall-clock call. |
|
Persistent review updated to latest commit 00b0e28 |
PR Code Suggestions ✨No code suggestions found for the PR. |
1 participant
User description
Donations were invisible
The addresses were technically present and practically undiscoverable — one line at the very bottom of the README pointing at
DONATE.md. Anyone who wanted to support the project had to go hunting for how.Now:
Same content and same addresses. Just findable.
Contributors
A contributors section crediting the people who made it better — mostly by wearing it on a real wrist and reporting what came out wrong. Worth saying out loud, since otherwise there's exactly one person's physiology in the test data.
Star chart — self-hosted, deliberately
I tried the two obvious services first. Neither works:
GitHub restricted starred-data access for openstrap/edge{"error":"rate limited, please try again later"}Beyond both being unreliable, both would make every visitor's browser call a third party. GitHub proxies README images through camo so it wouldn't leak there — but the landing page has no such protection, and a page whose argument is "your data stays on your device" shouldn't quietly be making outside requests.
So
tool/gen_star_history.pypulls the stargazer timestamps and emits a plain SVG — no script, no external reference, theme-aware light/dark — and.github/workflows/star-history.ymlregenerates it weekly, committing only when it actually changed.It plots all three repos, and makes the real story legible:
That cliff is Hackaday and Adafruit on the same day (2026-07-15) — ~40% of all stars arrived in the following 48 hours. More honest than a bare star count.
On "GitHub trending"
There's no trending badge to add — GitHub exposes no trending API, and the third-party ones (Trendshift and similar) require being featured, which you apply for rather than embed. The downloads + stars badges and the growth chart are the closest honest equivalent, so that's what's here.
Two things worth reviewing
star-history.ymlneedscontents: writeto commit the regenerated SVG. That's a deliberate exception to the read-only default I set on the test workflow last week, scoped to this one job.raw.githubusercontent.com. Reworded to state exactly what's true: the chart is self-hosted, there's no analytics or third-party service, and the images come from GitHub. Same standard as the "no cloud" fix in ci + docs: test gate on PRs, TestFlight install, landing page, contributor on-ramp #154.Docs, one workflow and one script only — no Dart touched, so nothing in the test suite is affected.
PR Type
documentation, enhancement
Description
Donation addresses moved to prominent positions in README and landing page
Added contributors section (contrib.rocks) and star history chart to README
Self-hosted SVG star history chart generated via new Python tool, avoiding third-party services
Weekly GitHub Actions workflow regenerates and commits the star chart when changed
Diagram Walkthrough
File Walkthrough
star-history.yml
Weekly CI workflow to regenerate self-hosted star chart.github/workflows/star-history.yml
tool/gen_star_history.pyand commitsdocs/star-history.svgonly whenit changed
contents: writepermission scoped to this job;workflow_dispatchalso supported
README.md
Promote donation, contributors, and star history in READMEREADME.md
after the Install section
docs/star-history.svgwithcontext about the Hackaday/Adafruit spike
DONATE.md
index.html
Landing page: prominent donate block and star history sectiondocs/index.html
#supportanchor.donateblockcontaining BTC/EVM addresses and explanatory fineprint
.growthsection embedding the self-hostedstar-history.svgwith explanatory caption
style.css
CSS for donate block and star history section on landing pagedocs/style.css
.growthstyles for the star history image (responsive, bordered,rounded)
.donateblock styles: accent-coloured border, backgroundsurface, prominent heading
.donate-lede,.donate .fineprint, and.addr coderules forlayout and mobile word-break on long crypto addresses
gen_star_history.py
Python tool to generate self-hosted SVG star history charttool/gen_star_history.py
three OpenStrap repos
SVG with no external references or scripts
docs/star-history.svg; includes y-axis rounding,legend, and timestamp
Summary by CodeRabbit
Documentation
New Features