GitHub's /contributors endpoint is heavily cached and can lag a merge by up
to a day. dakshverma23's commit from #129 was already linked to their account
- /commits reports it, and the commit API confirms the link - but they were
absent from the contributor wall because /contributors had not refreshed.
update-contributors.py now unions the two endpoints: /contributors for the
authoritative counts and ordering, /commits for anyone linked but not yet
surfaced. Commits authored with an unlinkable email still appear in neither,
which matches what GitHub's own contributor graph shows.
Wall goes from 13 to 14.
The Thanks-to-our-contributors block was hand-maintained and had gone stale:
it listed 8 people where the API reports 13, omitting valorisa (second by
contribution count with 18), Daytona39264, kevglynn, OctoBored and farhan6667.
tools/update-contributors.py regenerates the block between
<!-- contributors:start --> and <!-- contributors:end --> from the GitHub
contributors API, ordered by contribution count, bots excluded, with the
contribution count in each avatar's tooltip. It has a --check mode and
refuses to write an empty wall if the API returns nothing.
.github/workflows/update-contributors.yml runs it on push to main, weekly,
and on demand, committing only when the block actually changes. The weekly
pass exists because the contributors API is cached and can lag a merge by
about a day, so a push-triggered run alone would miss people.
Avatars come from github.com/<login>.png rather than a third-party
contributor-image service. A README image is fetched on every page view, so
an external host would be an uncontrolled dependency in the most-viewed file
in the repository - the same objection raised against the star-history
endpoint swap in #124.
Mahipal