This repository explains the machine underneath a workflow
Runner Images contains the definitions used for GitHub-hosted Actions runners and Microsoft-hosted Azure Pipelines agents. That makes it unusually useful during a CI incident. Instead of guessing whether an SDK, browser, compiler, or database client changed, you can open the inventory for the exact operating-system label and compare releases. The repository listed 18 current or deprecated image variants when we fetched it, spanning Ubuntu, macOS, and Windows across x64 and Arm64.
It does not contain the GitHub Actions runner application. Think of it as the recipe and manifest for the virtual machine that receives a job. The distinction matters because cloning this code will not register a runner with your organization. If you only want to run a workflow locally, act runs GitHub Actions jobs in containers. This project becomes relevant when the operating system and preinstalled toolchain are the thing you need to inspect or control.
Weekly image changes make loose labels a maintenance choice
GitHub says these images normally receive software updates every week. The ubuntu-latest, macos-latest, and windows-latest labels move to newer generally available operating systems through migrations that can take 1 to 2 months. That gradual rollout limits abrupt changes across the fleet, but two jobs using the same loose label can encounter different image generations during a migration. Pin an explicit OS label when the underlying version matters.
The support policy keeps at most 2 generally available images and 1 beta image for an operating-system family. Tools are typically removed 6 months after deprecation or end of life, and default-version changes normally receive 2 weeks of notice. These are practical rules for workflow owners: subscribe to releases, read announcements, and check the Set up job output for the image version that actually handled a failure.
What happened when we ran it
We did not execute the install, build, or tests for commit ede07f8. Our harness found a PowerShell project with no Dockerfile, and the fresh Debian container did not provide a supported ecosystem for its image-generation path. There are no legitimate timing, dependency, or test figures to publish from that sandbox. Treating an Azure VM image build as a normal package build would have produced a misleading result.
The absence of a lab run is useful here because it exposes the real boundary. The documented route starts with PowerShell 5.0 or newer, Packer 1.8.2 or newer, Git, Azure CLI, a subscription, and an existing resource group. Packer then creates a temporary Azure VM, connects through SSH or WinRM, runs the provisioning steps, creates a managed image, and removes temporary resources when the process succeeds.
Building an image means granting Azure control
An automated build needs a service principal plus subscription, tenant, location, and resource-group values. Windows builds also require an installation password. The instructions discuss TCP ports 22 and 5986 because the build agent must reach the temporary VM. You can restrict a public interface to the agent's address or use a private virtual network, but either route belongs in an infrastructure review, not in a casual developer bootstrap.
The repository supports 6 documented image types in its manual helper: Windows Server 2022, two Windows Server 2025 variants, and Ubuntu 22.04, 24.04, and 26.04. macOS appears in the hosted inventory, yet the published Azure build guide focuses on Windows and Ubuntu. Teams seeking one recipe across every hosted platform should notice that gap before writing automation around the helper module.
Old tags document contents but do not promise reproducibility
The README explicitly warns that current builds are not idempotent. Branches and releases record what software appeared in an image, but rebuilding a particular tag is not guaranteed to work. Package repositories move, installers disappear, and upstream defaults change. For compliance work, archive the generated artifact and its build evidence instead of treating the Git tag as a reproducible binary source.
That warning changes how we would use Runner Images internally. We would borrow its tool inventory and provisioning logic, pin every external input we control, then test our own artifact. Post-generation scripts are meant to run on a VM deployed in Azure, and Linux expects a default user with sudo privileges. A successful Packer command is one stage of the lifecycle, not proof that the resulting runner is ready for untrusted jobs.
Current activity matches a production image project
GitHub showed 13,228 stars, 132 combined open issues and pull requests, and a last push on September 25, 2026. The latest release we fetched was the September 23 Windows Server 2025 image update. Recent issue activity covered an intermittent Chrome repository failure on Ubuntu, a Go installation fix on Windows Arm, and an announced ubuntu-latest move to Ubuntu 26.04. Those topics match the repository's operational purpose.
Runner Images earns a place in the bookmarks of anyone responsible for hosted CI. It is also credible source material for an Azure image maintained by an experienced platform team. The line to keep clear is simple: its 18 listed hosted variants tell you what GitHub operates, while your custom build remains your own cloud system to secure, reproduce, and support.