GitLab Release Link Contract Monitor

Watch the attached asset links of one exact public GitLab.com release. Detect a link being added, removed, renamed, pointed at a different URL, assigned another link type, or given a changed direct asset URL. Keep a persistent before/after history and optionally check required link names.

This serves teams pinning release tags in installation or deployment workflows. A new-release feed does not necessarily reveal edits to an existing release's links. This Actor checks that fixed release repeatedly rather than reporting new releases or latest versions. Use GitLab's own APIs or webhooks if you prefer to maintain your own state and integration.

Start a monitor

{"project":"gitlab-org/cli","tag":"v1.50.0","monitorName":"default","requiredLinkNames":[],"includeUnchanged":true}

Use namespace/project, including nested groups, and an exact existing tag. GitLab.com only; no self-hosted host or token is accepted. Project components use ASCII letters, numbers, underscore, dot and hyphen; tags also permit plus and internal slashes. URL-encoded strings or arbitrary URLs are rejected. Reuse the same monitor name for history. Set a new name to start a separate baseline. Required-name preferences do not reset history. Apify Tasks and Schedules can repeat a saved input.

Results

One dataset row per successful check by default: BASELINE, CHANGED or UNCHANGED. A CHANGED row contains LINK_ADDED, LINK_CHANGED or LINK_REMOVED entries with stable link IDs and previous/current values. Name, URL, linkType and directAssetUrl are compared. It includes previous/current snapshots, checkedAt, sourceUrl, contractWarnings and missingRequiredLinkNames.

Required link names are exact and case-sensitive, and refer to attached release links, not the auto-generated source archives. REQUIRED_LINK_NAMES_MISSING flags missing names. These checks only assess declarations; they do not prove a link works or a binary is safe. OUTPUT in the run's default key-value store summarizes the check even when unchanged rows are suppressed.

Safe history and scope

A snapshot advances only after output delivery and the successful-check charging event. Failed source requests, incomplete metadata, unsupported fields or failed delivery retain the last committed snapshot. Complete asset counts must match the source-archive and attached-link arrays before removals can be reported. A release disappearing produces a failed check, not an inferred removal of all links. A bounded best-effort lease rejects overlap; avoid concurrent runs of the same monitor because platform key-value storage is not an atomic lock. An interruption after charging may leave delivered output without an advanced snapshot; a retry can repeat changes and charges.

History is separate by user, Actor, project, tag and monitor name in named key-value storage. It remains until deleted or platform retention changes; removing it starts a baseline. No author data, commit emails or issue text is collected. Link URLs and direct URLs are retained as declared text and never followed. HTTP/HTTPS/FTP source link declarations are supported without fetching their targets; credential-bearing target URLs are rejected. Exported URLs are untrusted content.

Pricing and limits

$0.01 per successful release link check, including baseline and unchanged checks. Platform usage included; no startup or dataset-row charge. Failed source checks are not charged. One project/tag per run, at most 500 attached links, source response capped at 2 MB, 20-second network deadline, same-origin source redirects only. Default run limits: 60 seconds, 256 MB, $0.05 maximum charge. Set a run maximum charge of at least $0.01.

No binary downloads, checksums, vulnerability scanning, newest-release discovery, pagination across releases, release note changes, tag commit verification, private repositories, credentials, proxies or automatic corrective actions. GitLab release links contain metadata, not content hashes. Public API feature restrictions, rate limits or schema changes can prevent checks. Empty attached-link arrays are valid when the complete source count matches; a baseline still returns a row.

Dependencies and support

Node.js and Apify SDK 3.7.2 with a pinned lockfile. Native HTTPS source requests use no cookies or response cache. The known transitive http-cache-semantics advisory GHSA-ch52-4w7c-c8xp has no published fix as checked October 5, 2026. This source client does not use the cross-user response-cache scenario; the SDK dependency tree is not asserted vulnerability-free. Follow-up is recorded.

Report issues with project, exact tag, monitor name and run ID. Never post tokens. Unaffiliated with GitLab. Official references: https://docs.gitlab.com/api/releases/ and https://docs.gitlab.com/api/releases/links/ .