Tell the site when a release is published - #9
Merged
Merged
Conversation
The site reads the version and the download size from a file in its own repository, and a schedule there kept that file current by asking this repository every half hour. GitHub does not honour that schedule: on a repository this quiet it drops the ticks rather than queueing them, and the measured gaps run from two to six hours. Every release spent an afternoon with the website offering the previous version. Publishing a release now pokes the website's repository directly, which rebuilds in seconds. The schedule stays on the other side as a safety net. Without SITE_DISPATCH_TOKEN this warns and passes rather than failing: a red cross on a release that published perfectly reads as a broken release rather than as a missing setting. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
The site reads its version and download size from a file in its own repository, so it asks GitHub nothing while it builds. A schedule on that side kept the file current by polling this repository every half hour.
GitHub does not honour that schedule. On a repository with little traffic it drops the ticks rather than queueing them. Measured on each site's own workflow runs, the real gaps:
So every release spent between two and six hours with the website still offering the previous version. That is what happened to Unbury 0.1.1 today, and it has been happening quietly to all three for weeks.
What this does
Publishing a release pokes the matching website repository directly, and it rebuilds in seconds. The schedule stays on the other side as a safety net for the case where this step fails.
It needs one secret, and works without it
SITE_DISPATCH_TOKEN— a fine-grained token with Contents: write on the site repository, which is whatrepository_dispatchrequires.Until that secret exists the step warns and passes rather than failing. A red cross on a release that published perfectly reads as a broken release rather than as a missing setting, and the site still catches up on its own schedule in the meantime — hours late, but correct.
permissions: {}— nothing here reads or writes this repository. The only credential is the one that reaches the other one.