Summary
test/typescript/terraform-cloud/test.ts feeds the CI matrix's Terraform version straight into an HCP Terraform workspace. That coupling breaks as soon as the matrix carries a non-Terraform product, so it is a blocker for adding an OpenTofu leg to the integration matrix (discussed in #337).
Detail
The test reads TERRAFORM_VERSION from the environment and uses it as the workspace's terraformVersion attribute when creating the workspace:
// test/typescript/terraform-cloud/test.ts:7
const { TERRAFORM_CLOUD_TOKEN, GITHUB_RUN_NUMBER, TERRAFORM_VERSION } = process.env;
// test/typescript/terraform-cloud/test.ts:47
attributes: { name, executionMode: "remote", terraformVersion: TERRAFORM_VERSION }
TERRAFORM_VERSION is set from the matrix axis in .github/workflows/integration.yml:109 (linux) and :192 (windows):
TERRAFORM_VERSION: ${{ matrix.terraform }}
Under an OpenTofu matrix leg that value would be an OpenTofu version (e.g. 1.12.6), and the test would ask HCP Terraform to create a workspace pinned to Terraform 1.12.6 — not a Terraform release. HCP Terraform executes Terraform remotely and exposes no OpenTofu equivalent through this API, so there is no correct value to pass here for a tofu leg. The resulting failure would be entirely unrelated to the behaviour the test covers.
The test is guarded by TERRAFORM_CLOUD_TOKEN (const withAuth = TERRAFORM_CLOUD_TOKEN ? onPosix : it.skip), so it skips on forks — but it would fire on main and release runs, where the token is present.
Options
- Exclude this target from non-Terraform legs in
tools/build-test-matrix.mjs (the matrix builder already owns which targets appear per entry).
- Have matrix entries carry product + version rather than a bare version string, and skip the test when the product is not
terraform. This overlaps with the binary-selection work needed anyway — TERRAFORM_BINARY_NAME: "terraform${{ matrix.terraform }}" string-concatenates the same axis.
- Pin
terraformVersion to a fixed, known-good Terraform release independent of the matrix axis, since the test is about the cloud backend rather than about version coverage.
Relations
Summary
test/typescript/terraform-cloud/test.tsfeeds the CI matrix's Terraform version straight into an HCP Terraform workspace. That coupling breaks as soon as the matrix carries a non-Terraform product, so it is a blocker for adding an OpenTofu leg to the integration matrix (discussed in #337).Detail
The test reads
TERRAFORM_VERSIONfrom the environment and uses it as the workspace'sterraformVersionattribute when creating the workspace:TERRAFORM_VERSIONis set from the matrix axis in.github/workflows/integration.yml:109(linux) and:192(windows):Under an OpenTofu matrix leg that value would be an OpenTofu version (e.g.
1.12.6), and the test would ask HCP Terraform to create a workspace pinned to Terraform 1.12.6 — not a Terraform release. HCP Terraform executes Terraform remotely and exposes no OpenTofu equivalent through this API, so there is no correct value to pass here for a tofu leg. The resulting failure would be entirely unrelated to the behaviour the test covers.The test is guarded by
TERRAFORM_CLOUD_TOKEN(const withAuth = TERRAFORM_CLOUD_TOKEN ? onPosix : it.skip), so it skips on forks — but it would fire onmainand release runs, where the token is present.Options
tools/build-test-matrix.mjs(the matrix builder already owns which targets appear per entry).terraform. This overlaps with the binary-selection work needed anyway —TERRAFORM_BINARY_NAME: "terraform${{ matrix.terraform }}"string-concatenates the same axis.terraformVersionto a fixed, known-good Terraform release independent of the matrix axis, since the test is about the cloud backend rather than about version coverage.Relations