Releases whose tag starts with any of tagPrefixes, newest published first.
The ordering is explicit rather than inherited from the API. GitHub lists releases by internal creation order, which is not the publish order when a build pipeline creates several releases in one run, and the live listing has already held releases out of publish order. "Behind by N releases" counts positions in this list, so the sort is load-bearing, not cosmetic.
Drafts are dropped: they carry no publicly fetchable asset, so a draft in the list would be a release whose hash can never resolve. Prereleases are kept — a prerelease is a real build someone may have deployed.
Returns err GITHUB_ERROR for a 4xx GitHub answers other than
401/403/408/429 (such as a repo that does not exist); a fault throws.
The asset's bytes as a stream.
Streamed rather than buffered because the caller hashes program binaries: ~900 KB each, and a register paint covers every release of every program. Buffering them would make peak memory a function of how many times the team has shipped.
GitHub answers this with a redirect to object storage. fetch follows it
and drops the Authorization header on the cross-origin hop, which is
what object storage requires — sending it through produces a 400 from a
signed URL that needed no credential at all.
null when the asset does not exist.
owner/name, so a caller can key a cache by the repo it reads.
Read-only client for a repository's GitHub Releases.
The platform's first GitHub client. It exists because the program register (docs/proposals/PROGRAM_DEPLOYS.md § 3.2) needs to read the mintfx program release artifacts, and no client talked to GitHub.
Deliberately not an Octokit wrapper: three endpoints, no pagination beyond releases, no writes. The dependency would be larger than the client.