GitHub Release Asset Contract Monitor

Keep an exact-tag download contract under observation. Check a public GitHub release for assets added, changed or removed after publication, and report missing filenames your installer or distribution workflow expects. History persists in Apify, so you do not supply a previous release record on every run.

Who it helps

Release engineers, package distributors and teams depending on a particular upstream release can watch asset IDs, names, labels, sizes, MIME types, download URLs and GitHub-reported digests. A replacement upload with the same filename has a new asset ID and is reported as an addition plus a removal. This checks metadata without downloading binaries.

Input

{
  "repository": "cli/cli",
  "tag": "v2.78.0",
  "monitorName": "github-cli-downloads",
  "requiredAssets": ["gh_2.78.0_linux_amd64.tar.gz"],
  "includeUnchanged": true
}

• repository: a public owner/repository on github.com. No private repositories or tokens.
• tag: exact release tag, not latest. Keep it stable across checks.
• monitorName: independent baseline name. Use the same name to compare subsequent runs. Different users, Actors, repositories and tags have independent history.
• requiredAssets: exact, case-sensitive asset filenames. Missing names are reported in the summary, including on the first check.
• includeUnchanged: emit UNCHANGED asset rows on repeat checks (default true).

Output

The dataset contains BASELINE, ADDED, CHANGED, REMOVED and optionally UNCHANGED rows with asset ID, name, changed properties, previous/current metadata, repository, tag, release ID and check time. The OUTPUT key-value record reports counts, missing required assets, digest coverage and any prerelease-state change. If a release has no assets or unchanged rows are suppressed, a successful check can have an empty dataset; consult the summary.

An asset's download count and timestamps alone do not trigger a change. GitHub's optional digest is recorded as reported; a null digest means unavailable. The Actor does not independently verify file integrity, detect byte changes when GitHub metadata does not change, or guarantee an upstream release is safe. It does not fetch source archives or binaries.

Persistent checks and failure behavior

The first successful check establishes a baseline. Later successful checks compare with the last committed snapshot. HTTP errors, API quota limits, incomplete responses, duplicate assets, unfinished uploads and unsupported metadata fail without advancing the committed snapshot. Failed source checks are not charged the asset-check event. A tag unexpectedly pointing to a different release ID fails; choose a new monitor name to explicitly establish a new baseline.

Public unauthenticated GitHub REST calls are subject to GitHub's shared-IP rate limits (normally 60 requests/hour/IP). Each check makes two bounded metadata requests. This Actor does not retry quota errors, request credentials or use paid proxies. A check can fail when Apify's egress IP has exhausted its GitHub allowance; try later. Maximum supported assets per release: 99. A 100-item response is conservatively rejected rather than risking false removals from pagination. Each response is capped at 2 MB, each request at 20 seconds. The two responses are sequential observations, not an atomic GitHub snapshot.

Run one check at a time per monitor. A best-effort lease reduces overlap but is not an atomic lock. On an abort, the committed history is preserved; a lease can take five minutes to expire. Dataset output and successful-check billing precede snapshot commit; interruptions can leave output without a new committed baseline. Delivery is at least once, not exactly once. Required-asset changes do not change the source identity.

Pricing

$0.01 per successful asset metadata check. Baseline and unchanged checks count. One event per successful check, regardless of asset count, with platform usage included in this pay-per-event price. There is no per-asset, per-download or startup charge. A missing required filename on a complete source response is a successful billed check. No guarantee of demand, revenue or continuous upstream availability.

Scheduling

Use an Apify schedule with the same input and monitor name. Start with infrequent checks to respect GitHub limits. Use dataset/summary exports or your own integrations to handle alerts; this Actor does not send email or messages itself.