mattrobinsonsre/terrapod v1.10.4

on GitHub

Terrapod is a free, open-source, self-hosted platform replacement for Terraform Enterprise. This patch makes Google Cloud Storage work — in both directions, for the first time — and corrects what the API tells a client about a failed apply.

Bug Fixes

• Uploads to Google Cloud Storage never worked. put_stream passed a num_retries keyword that google-cloud-storage 3.x removed, and its reader refused tell(), which the resumable upload needs for each chunk's byte range — so every streamed write to a GCS bucket failed: configuration versions, run artifacts, state versions, the binary and provider caches, registry modules and backups. The chart has pinned ^3.9.0 since the project's first commit, so if you configured storage.backend: gcs, this is the release that makes it work.
• And downloads leaked until the API stopped working. get_stream left its reader thread parked forever whenever a consumer stopped early, holding a thread, a ~40 MiB read buffer, an open connection and — the part that mattered — an asyncio.to_thread worker from the process-wide default executor. Once enough downloads had been cancelled, every other threaded storage operation starved, including the uploads the first fix had just repaired. A cancelled download is routine: a tofu client interrupting a configuration fetch, or any browser abandoning one, was enough. Both fixes came from an outside contributor, @MyLittleChicken.
• A hanging Redis cannot stall a run's artifact upload. The run-notification publishes are best-effort and were unbounded, so a partitioned Redis blocked the upload — including the state upload, where a stall can collide with the shutdown grace window — instead of simply skipping the notification.
• Cloud-identity discovery reads the workspace's variable files. Discovery ran tofu graph with none of the workspace's var_files, so a configuration whose module version or count comes from a variable failed before the plan ever started. The flag is passed where the engine advertises it on graph.
• A broken engine binary no longer kills the run. The capability probes caught only "file not found", so a binary that exists but cannot be executed — a wrong-architecture download from the binary cache — or a runner at its fork limit raised out of a code path documented as never raising, failing runs that configure no cloud identity at all. The init-phase warning also no longer blames the engine's version for a failure it cannot attribute.
• A failed discovery names what the engine could not resolve, with the engine's own Error: summary and detail rather than a truncated fragment, and two identical diagnostics no longer swap their details.
• A one-to-one agent-pool change on terrapod_workspace neither warns about "several pools" nor fails the apply with an inconsistent agent_pool_name.
• The run Overview's Changes and Cost cards populate without a reload. Three artifact uploads write columns the page renders and changed no run status, so nothing told the browser; the cost one lands roughly fourteen seconds after the plan finishes.

Changed behaviour

• A failed apply now reports errored, not unreachable. Every failed apply previously reported unreachable — "the apply never ran" — on the apply.status field of a run's nested applies resource. tofu and terraform are unaffected: neither reads that sub-resource. If you have third-party go-tfe automation that branches on unreachable to mean "safe to re-run without inspecting state", re-read it — that value is now reserved for applies that genuinely were not dispatched.

  One honest limit: errored means "dispatched and did not succeed", which is not quite "the engine ran". A run whose Job never produced a running pod — an image that could not be pulled, a cluster with no room — also reports errored despite having mutated nothing. Distinguishing those needs a signal the API does not store, so automation treating errored as "state may be partially applied" is over-cautious there rather than wrong. The full vocabulary is now in api-reference.md.

• terrapod_workspace plans may show agent_pool_name and vcs_connection_name as (known after apply) when the corresponding id changes. They are derived from the server, and showing the previous name would be promising a value that is about to be wrong — which Terraform would then refuse at apply.

Documentation

• Use an absolute path for var_files on a Terragrunt workspace. Measured for this release: Terragrunt runs the engine inside its own .terragrunt-cache copy of the unit, so a relative -var-file is resolved there rather than beside your terragrunt.hcl — which fails the plan, not merely discovery. cloud-identity.md now says so, and no longer claims the graph answers for any configuration whose plan would refuse.
• api-reference.md documents the apply-status vocabulary, which had no entry at all.

Status

Stable — a patch release on the 1.10 line. No schema changes, no API route or attribute changes, and no migrations.

Full Changelog: v1.10.3...v1.10.4