Ignore changes to MIG version block on runner instance group manager

[carolinetaymor-qz]

Hi! Another patch from our vendored copy as we move onto the published module.

Summary

Adds ignore_changes = [version] to the lifecycle block on google_compute_region_instance_group_manager.runner so terraform yields ownership of the version block to the runner control plane, which manages it as part of the runner's self-update mechanism.

Motivation

When applying changes to the runner MIG, wait_for_instances = true can fail to converge because the control plane continuously manages version[0].instance_template and version[0].name as part of the runner's application-level self-update. Each terraform apply that touches the version block then races against the control plane re-setting those fields, and wait_for_instances never sees a stable target.

We observed this concretely at v2.0.1: applying a routine change to the runner workspace timed out after 15 minutes on wait_for_instances, with the control plane and terraform alternating writes to version[0].instance_template. After adding ignore_changes = [version] the same apply completes cleanly.

Change

ignore_changes = [version] on the MIG lets the control plane own version[0].instance_template and version[0].name without terraform refresh/apply re-asserting the bootstrap template. The rest of the resource (named ports, auto-healing, update policy, etc.) is still managed by terraform as before.

Trade-off

With this change, an operator who wants to push their own instance template changes through terraform (e.g. machine type bumps, disk size changes, image updates that aren't coming from the control plane) needs to either temporarily remove ignore_changes or use terraform apply -replace=google_compute_region_instance_group_manager.runner.

We think this is the right trade-off because customer-driven template changes are rare and intentional, while control-plane self-updates are continuous and the current behavior makes routine applies unreliable. Flagging it explicitly though in case there's a use case I'm not thinking of.

Testing

• terraform fmt -check -recursive clean
• terraform init -backend=false && terraform validate clean
• Running with this patch in our vendored copy, the apply that previously timed out now completes
• No variable/output changes, so no terraform-docs regen