Codespaces prebuild freshness limits after devcontainer changes
0 reputation · 25 Oct 2020, 14:33 UTC
Prebuild freshness after devcontainer changes
GitHub Codespaces prebuilds assemble a dev container image, features and onCreateCommand ahead of time so new codespaces start faster. The prebuild is a snapshot tied to a specific devcontainer.json and repository branch, and its usefulness degrades when the template changes.
Refresh behavior depends on the configured prebuild update trigger. When a codespace is created from a stale prebuild, the container image may be old, while content update steps such as updateContentCommand and postCreateCommand still run against the latest commit. That partial update can mask a stale image without rebuilding changed images or features.
Prebuild storage is billed and availability can be limited by region and machine type, so organizations must balance refresh frequency against cost. The unresolved decision is which template modifications reliably force a prebuild to be considered out of date versus being silently reused, and whether freshness can be confirmed from the UI.
Does a change to the base image or features always invalidate existing prebuilds for the configured branch? Is there a documented way to determine whether a newly created codespace used a current prebuild or a stale snapshot? How do region and machine type limits affect prebuild availability when freshness is required?