💡 Runner Version Deprecation Lifecycle Compliance Gate

[github-actions[bot]]

Summary

GitHub's new Runner Deprecation API (September 2026) exposes deprecation timelines for self-hosted runner versions, and full enforcement of minimum version requirements begins September 25, 2026. This proposes an org-wide compliance check that queries this API, warns about approaching deprecations, and fails CI when a runner version is within N days of its runtime_deprecates_at date — preventing enforcement-day breakage across the fleet.

Market Signal

• Runner Deprecation API (Sep 2026 changelog): New GET /actions/runners/deprecations/{version} endpoint returns runner_version, runtime_deprecates_at, and registration_deprecates_at at repo/org/enterprise level
• Full enforcement deadline: September 25, 2026 for GitHub Enterprise Cloud — runners below minimum version will stop executing workflow jobs
• Brownout ramp: Began August 24, escalating through mid-September, with increasing failure windows
• GitHub is signaling that runner version lifecycle management is now a first-class operational concern, not something orgs can ignore

User Signal

• Issue fix: kcov not available on ubuntu-24.04 (ubuntu-latest) — coverage job breaks when bats tests exist #867 (kcov not available on ubuntu-24.04) demonstrated that runner image transitions break CI unexpectedly when there is no proactive detection mechanism
• Discussion 💡 Runner Image Migration Readiness & Fleet Testing Standard #897 proposed a Runner Image Migration Readiness standard but focused on image transitions (ubuntu-latest → ubuntu-24.04), not version deprecation lifecycle
• The org has no proactive mechanism to detect approaching runner deprecations before they cause failures
• The compliance-audit framework checks many things but not runner version health

Technical Opportunity

The new REST API provides the data; the existing compliance-audit.sh framework provides the execution model. A lightweight check can:

1. Query GET /actions/runners/deprecations/{version} for each runner version in use
2. Warn when any runner is within a configurable window (e.g., 30 days) of runtime_deprecates_at
3. Fail when a runner is past its deprecation date
4. Report findings in the standard compliance-audit format

The canary-ring pattern provides a safe rollout path for the gate itself. The pattern generalizes to GitHub-hosted runner image deprecations (which directly affected this org via #867).

Assessment

Dimension	Score	Rationale
Feasibility	high	API exists, compliance-audit framework exists, lightweight integration
Impact	med	Prevents enforcement-day breakage; generalizes to runner image transitions
Urgency	high	September 25 enforcement deadline is ~3 weeks away

Adversarial Review

Strongest objection: petry-projects primarily uses GitHub-hosted runners, not self-hosted runners. The enforcement deadline doesn't directly affect GitHub-hosted runner users.

Rebuttal: Even with GitHub-hosted runners, the org's CI standards are consumed by downstream repos that may use self-hosted runners (or may in the future). The same pattern applies to GitHub-hosted runner image deprecations (the ubuntu-24.04 transition), which DID affect petry-projects directly (#867). The gate is a general "runner lifecycle awareness" mechanism, not just for self-hosted. Codifying it in standards/ means the fleet is protected proactively, and the compliance check catches problems before they manifest as broken CI.

Suggested Next Step

Add a runner-version-deprecation check to compliance-audit.sh that queries the new API and reports runners within 30 days of deprecation. Include in the next compliance audit cycle. Use the existing compliance finding format so findings are tracked as issues.

[github-actions[bot]]

Weekly Update

What Changed

Two significant developments since last update:

1. New Runner Deprecation REST API (September 3, 2026): GitHub shipped a new REST API endpoint GET /actions/runners/deprecations/{version} that returns runner_version, runtime_deprecates_at, and registration_deprecates_at at repository, organization, or enterprise level. This is the programmatic interface this idea proposed — it now exists natively. (GitHub Changelog)

2. Node.js 24 Hard Deadline — September 23, 2026 (12 days away): Node.js 20 will be completely removed from GitHub-hosted runners on September 23, 2026. Starting June 16, 2026, runners default to Node 24. After September 23, workflows referencing Node 20 actions will fail with no opt-out or fallback. The FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true env var is available for pre-migration testing. (GitHub Changelog)

3. Self-hosted runner enforcement enforcement phased in: For GitHub Enterprise Cloud, brownouts began August 24 and ramp up through mid-September, with full enforcement beginning September 25, 2026. Runners on versions older than the latest release by more than 30 days will be rejected.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	high	high	→ (new API makes implementation even easier)
Impact	high	high	→
Urgency	med	high	↑ Node 24 deadline is 12 days away; self-hosted enforcement Sep 25

Recommendation

Advance — with immediate action on Node 24. The new Runner Deprecation API provides the programmatic foundation this idea needs. Immediate priority: audit all org workflows and pinned actions for Node 24 compatibility before the September 23 hard deadline. Use FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true in a CI test job to validate. Then build the ongoing compliance gate using the new deprecation API endpoint.

[github-actions[bot]]

Weekly Update

What Changed

GitHub shipped the Runner Version Deprecation REST API on September 3, 2026, providing the exact capability this proposal envisioned:

• Endpoint: GET /actions/runners/deprecations/{version} — available at repository, organization, and enterprise levels
• Response fields: runner_version, runtime_deprecates_at, registration_deprecates_at
• Purpose: Proactive visibility into when a runner version loses registration and runtime support

This API allows the compliance audit to programmatically check whether any self-hosted runner in the fleet is approaching deprecation, rather than relying on manual tracking or runner-image changelogs. Changelog

Additionally, a related update: GitHub now includes immutable subject claims for OIDC tokens (repos created after July 15, 2026 use immutable identifiers), strengthening the security foundation for runner-to-cloud authentication.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	med	high	↑ REST API now available; no scraping or manual tracking needed
Impact	med	med	→ Still prevents surprise deprecation; unchanged
Urgency	med	high	↑ API is GA; integration into compliance audit is now straightforward

Recommendation

Advance. The REST API eliminates the main feasibility blocker. Recommend adding a runner deprecation check to the weekly compliance audit: query the API for each runner version in use, flag any version within 30 days of runtime_deprecates_at, and open a finding issue if the deadline is approaching.