You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In one original manual GitHub-hosted ubuntu-24.04 job on November 4, 2026, the provider setup log and the environment value read by an inline metadata step disagree.
From the same original attempt log archive:
Set up job > Runner Image: image ubuntu-24.04, version 20261025.353.1. Its Included Software and Image Release links also use ubuntu24/20261025.353.
The inline Python step reads ImageOS=ubuntu24 and ImageVersion=20261026.354.1 from its environment. Its reported runner is Linux/X64/github-hosted.
The workflow has one preinstalled Python metadata step, no ImageVersion assignment, no checkout or downloaded action, and no container or application step. The job succeeded. Both version reports occur in the same original job archive and aggregate log; an independent ZIP/member CRC and byte comparison preserved the same discrepancy. It is not a comparison between different workflow jobs or attempts.
I retained the original attempt and have not rerun it. I need a consistent original-job image identity before admitting a separate isolated fixture; a future moving-label job is not being treated as pinned by this observation.
Is there a documented semantic reason these two same-job versions can differ? Which supported read-only evidence can reconcile the original reports, or establish that a provider metadata issue needs investigation? I will preserve both values and the original attempt rather than selecting one by guess.
This question contains only sanitized version reports and workflow behavior. Private repository/run URLs, source contents, credentials and raw logs are omitted. The supported Community route was recommended for this account.
ActionsBuild, test, and automate your deployment pipeline with world-class CI/CDQuestionAsk and answer questions about GitHub features and usagesource:uiDiscussions created via Community GitHub templates
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Question
💬 Feature/Topic Area
Actions Runner Image
Discussion Details
In one original manual GitHub-hosted ubuntu-24.04 job on November 4, 2026, the provider setup log and the environment value read by an inline metadata step disagree.
From the same original attempt log archive:
The workflow has one preinstalled Python metadata step, no ImageVersion assignment, no checkout or downloaded action, and no container or application step. The job succeeded. Both version reports occur in the same original job archive and aggregate log; an independent ZIP/member CRC and byte comparison preserved the same discrepancy. It is not a comparison between different workflow jobs or attempts.
I retained the original attempt and have not rerun it. I need a consistent original-job image identity before admitting a separate isolated fixture; a future moving-label job is not being treated as pinned by this observation.
The runner-images FAQ points to the setup log for a specific build: https://github.com/actions/runner-images#what-image-version-is-used-in-my-build
The Ubuntu image build script sets ImageVersion from IMAGE_VERSION: https://github.com/actions/runner-images/blob/main/images/ubuntu/scripts/build/configure-environment.sh
Is there a documented semantic reason these two same-job versions can differ? Which supported read-only evidence can reconcile the original reports, or establish that a provider metadata issue needs investigation? I will preserve both values and the original attempt rather than selecting one by guess.
This question contains only sanitized version reports and workflow behavior. Private repository/run URLs, source contents, credentials and raw logs are omitted. The supported Community route was recommended for this account.
All reactions