OptionalbaseUrl?: stringowner/name, e.g. CFXLabsInc/cfx-solana-program-library.
Releases whose tag starts with tagPrefix, 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 — two of the four
escrow-mainnet releases are out of publish order in the live listing
today. "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.
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.
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 artifacts that
cfx-solana-program-librarypublishes, and nothing inpackages/clientstalked to GitHub.Deliberately not an Octokit wrapper: three endpoints, no pagination beyond releases, no writes. The dependency would be larger than the client.