Three fresh additions to GitHub Actions deliver improved visibility into your automation pipelines and enable more precise control over workflow execution. These updates address runner lifecycle management, token-based access restrictions, and workflow identity tracking.
New REST API for runner version deprecations
A newly available REST API endpoint surfaces deprecation timelines for runner versions, allowing teams to schedule upgrades ahead of support windows closing. By calling GET /actions/runners/deprecations/{version} at the repository, organization, or enterprise level, you receive structured data about when a given runner version stops accepting new registrations and when its runtime support expires. The API response delivers runner_version, runtime_deprecates_at, and registration_deprecates_at fields.
New vulnerability-alerts permission for GITHUB_TOKEN
Workflows can now request read-only access to Dependabot vulnerability findings through a dedicated vulnerability-alerts permission attached to GITHUB_TOKEN. The permission accepts read and none values, enabling teams to implement least-privilege access models without granting unnecessarily broad token scopes. Additional details are available in the permissions key documentation for workflow syntax.
New job context properties for reusable workflows
Reusable workflows now have access to four new job context properties that expose the identity and location of the workflow file controlling the current job at runtime:
- job.workflow_ref: Complete reference path to the workflow file that specifies the current job
- job.workflow_sha: Commit hash of the workflow file
- job.workflow_repository: Owner and repository name containing the workflow file
- job.workflow_file_path: Relative path from the repository root to the workflow file
These job context values differ from the existing github.workflow_ref and github.workflow_sha properties in that they always point to the workflow defining the current job. When a job is defined directly in a workflow file, job.workflow_ref will match github.workflow_ref; differences emerge only when reusable workflows are involved. Note that these properties are unavailable on GitHub Enterprise Server installations. Refer to the job context documentation for comprehensive guidance.
Source: GitHub Blog