Problem statement
The v1.0.0-rc.1 release (PR #71, 2026-05-04) shipped GCP support and a public GCE image. The image build pipeline at .github/workflows/gce-image-build.yml currently publishes the image to only one GCP multi-region storage location (us), per the constraint surfaced by Packer's googlecompute plugin: Invalid image storage locations: Must not have more than 1 region.
Operators in Europe or Asia who want to deploy jit-runners on GCP via the public image have to pull it cross-continent for every new VM launch — a slow path that bottlenecks runner cold-start latency.
Description
Add a post-Packer step to gce-image-build.yml that replicates the freshly-built image to additional multi-region storage locations (eu and asia). Mirror the AWS-side ami-build.yml distribution pattern, which copies the source AMI to 9 regions after the Packer build completes.
The Packer plugin can't do this in one step — it limits each image to a single storage location at creation time. The follow-up replication uses gcloud compute images create --source-image=<built-image> --storage-location=<region>.
Who is this feature for?
Operators running jit-runners on GCP outside the US — Europe-based + APAC-based fleets. With single-region storage, cold-start latency is dominated by cross-Atlantic / cross-Pacific image pull. With image replicas in eu and asia, new VM launches in those continents pull the closest replica.
Acceptance criteria
References
- Spec D7 (Phase D-Packer) — committed the single-region default per googlecompute plugin constraint
- Spec D17 (Phase E) — listed multi-region GCE as an explicit out-of-scope item for v1.0.0
- Phase F closeout note: "Multi-region GCE replication to
eu/asia is deferred as a follow-up enhancement"
- AWS-side parity:
ami-build.yml already distributes to 9 AWS regions
Problem statement
The v1.0.0-rc.1 release (PR #71, 2026-05-04) shipped GCP support and a public GCE image. The image build pipeline at
.github/workflows/gce-image-build.ymlcurrently publishes the image to only one GCP multi-region storage location (us), per the constraint surfaced by Packer'sgooglecomputeplugin:Invalid image storage locations: Must not have more than 1 region.Operators in Europe or Asia who want to deploy jit-runners on GCP via the public image have to pull it cross-continent for every new VM launch — a slow path that bottlenecks runner cold-start latency.
Description
Add a post-Packer step to
gce-image-build.ymlthat replicates the freshly-built image to additional multi-region storage locations (euandasia). Mirror the AWS-sideami-build.ymldistribution pattern, which copies the source AMI to 9 regions after the Packer build completes.The Packer plugin can't do this in one step — it limits each image to a single storage location at creation time. The follow-up replication uses
gcloud compute images create --source-image=<built-image> --storage-location=<region>.Who is this feature for?
Operators running jit-runners on GCP outside the US — Europe-based + APAC-based fleets. With single-region storage, cold-start latency is dominated by cross-Atlantic / cross-Pacific image pull. With image replicas in
euandasia, new VM launches in those continents pull the closest replica.Acceptance criteria
gce-image-build.yml, additional steps rungcloud compute images createto replicate the source image toeuandasiamulti-regions.var.runner_imageURI pattern.pull_requesttrigger), only the single-region source image is published (matches existing private/cleanup behavior).workflow_dispatchwithdistribute=true, all three replicas (us,eu,asia) are published.us.References
eu/asiais deferred as a follow-up enhancement"ami-build.ymlalready distributes to 9 AWS regions