GitHub Actions introduced three concrete changes: a REST endpoint that reports runner version deprecation dates, a new vulnerability-alerts permission for GITHUB_TOKEN, and four job context fields that expose the identity of reusable workflow files. These updates affect upgrade planning, token‑scope hygiene, and provenance tracking for CI/CD pipelines that AI, cloud, DevOps, and security teams rely on.
Runner version deprecation API
A new GET endpoint /actions/runners/deprecations/{version} can be called at the repository, organization, or enterprise level. The response includes runner_version, runtime_deprecates_at, and registration_deprecates_at. This makes the deprecation timeline visible programmatically, allowing teams to script checks and schedule runner upgrades before support ends. For AI model training jobs or large‑scale data pipelines that depend on specific runner versions, early awareness reduces the risk of unexpected build failures. The API does not replace existing runner management tools but adds a query layer that can be integrated into monitoring dashboards or CI health checks.
Granular vulnerability-alerts permission for GITHUB_TOKEN
Workflows can now request a vulnerability-alerts scope on the automatically generated GITHUB_TOKEN. The scope accepts read or none, enabling a least‑privilege configuration for accessing Dependabot alerts. By limiting the token to read‑only alert data, security engineers can reduce the attack surface of compromised workflow runs. The change also clarifies intent in the workflow syntax, making permission reviews more straightforward. Teams should audit existing workflows that read Dependabot data and replace broader scopes with the new explicit permission where appropriate.
Job context properties for reusable workflows
Four new job context variables are now available inside reusable workflows: job.workflow_ref, job.workflow_sha, job.workflow_repository, and job.workflow_file_path. Unlike the existing github.workflow_ref and github.workflow_sha, these values reflect the source file that defined the current job, not the caller workflow. This distinction is useful when a job needs to make decisions based on its own version or repository, such as conditional steps that depend on the workflow’s commit SHA. The properties are unavailable on GitHub Enterprise Server, so teams using that platform must continue to rely on the older github.* fields.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Start by scripting periodic calls to /actions/runners/deprecations/{version} and integrating the dates into your CI health dashboard. Review all workflows that consume Dependabot data and switch to the vulnerability-alerts permission with read or none as needed. Update reusable workflow definitions to reference the new job.workflow_* fields for any logic that depends on the workflow’s identity, and verify that your GitHub Enterprise Server instances have a fallback strategy. Monitoring these three changes will help keep pipelines reliable, secure, and auditable.
