Repository navigation
build(terraform): record linux and darwin provider hashes in every lock file, init env roots with -lockfile=readonly - #1439
Conversation
…files The federation roots' lock files recorded one platform's h1: hash per provider, so `terraform init -lockfile=readonly` and `terraform validate` failed on Linux and a plain init rewrote the lock file (LeanerCloud#1435). Regenerated with `terraform providers lock` for linux_amd64, linux_arm64, darwin_arm64 and darwin_amd64. Provider versions are unchanged; the constraints lines are what terraform writes for the current config. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… files Same regeneration as the federation roots (LeanerCloud#1435), for the three environment roots and their ci-cd-permissions roots. CI initialises the environment roots on linux_amd64 and the deploy jobs run on linux_arm64, so both need hashes before init can be made strict. Provider versions are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Same regeneration (LeanerCloud#1435) for every module lock file. Modules without Linux hashes could not get readonly-init tests in CI without a lock fix first, as LeanerCloud#1086 found for modules/database/aws. Provider versions are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A plain `terraform init` quietly adds the runner's hashes to a lock file that lacks them, which is how single-platform lock files went unnoticed (LeanerCloud#1435). The Terraform Init and CI/CD trust steps now use -lockfile=readonly, so a lock file without linux_amd64 hashes fails the job. The ci-cd-permissions comment said its lock file is gitignored; it is committed. TestLockFilesRecordEveryPlatform also fails when a committed lock file records fewer than four h1: hashes per provider, which catches a single-platform lock in the unit tests before CI's init runs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reached
This review includes 44 billable files and costs up to $11.00. Or wait 59 minutes for your next included review. View limit details
Comment |
|
Opened at head |
|
Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: APPROVE Blocking:
Non-blocking:
Attacked:
Body-stale:
Reviewer: rC2. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths. |
|
Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: APPROVE Blocking:
Non-blocking:
Attacked:
Body-stale:
Reviewer: rC3. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths. |
|
Local verification at |
|
Merged by IAmJSD's agent at IAmJSD's request (IAmJSD is acting owner while the maintainers are away), under the bar IAmJSD set: 2 approving independent review(s) on |
Bring the branch up to date with main. The only conflicts were the two Azure compute lock files (aks, container-apps). Main's versions already carry linux_amd64, linux_arm64, darwin_arm64 and darwin_amd64 hashes (LeanerCloud#1439) for the same provider versions this branch pins, so main's files were taken and re-checked with `terraform providers lock` for all four platforms, which reported no changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Closes #1435
Root cause
24 of the 42 committed
.terraform.lock.hclfiles recorded one platform'sh1:hash per provider (darwin, from whoever ranterraform init), and most of the rest recorded three. On Linux,terraform init -lockfile=readonlythenterraform validatefails with "the cached package ... does not match any of the checksums recorded in the dependency lock file", and a plain init quietly adds the Linux hashes to the working copy. CI never noticed because itsTerraform Initstep for the environment roots ran a plainterraform init -backend=false.Fix
terraform providers lock -platform=linux_amd64 -platform=linux_arm64 -platform=darwin_arm64 -platform=darwin_amd64(Terraform 1.10.5). Roots that call local modules neededterraform getfirst. These diffs are mechanical: they addh1:lines and refresh theconstraints = ...line terraform writes for the current config. No provider version changed (all 81provider/versionpairs compared before and after), and no existingh1:/zh:line was removed. I did all 42, not only the 24 single-platform ones, because the three-hash files were also missing a platform..github/workflows/ci.yml(terraform-validate job):Terraform Initnow runsterraform init -backend=false -lockfile=readonly -input=false.Test CI/CD trust (immutable ids)also gets-lockfile=readonly. Its comment said that lock file is gitignored, but all three are committed (terraform/.gitignorere-includes them).terraform/lock_platforms_test.go(TestLockFilesRecordEveryPlatform): fails when a lock file underterraform/oriac/federation/records fewer than 4h1:hashes for a provider. A lock file doesn't say which platform a hash is for, so this only checks the count. CI's readonly init on linux_amd64 is the check for the platform itself.Commits are split by area (federation / environments / modules / CI + test). Each is under 400 lines.
The deploy workflows still use plain
terraform init -backend-config=.... I left them alone because they're outside the issue's acceptance criteria, and they now find the linux_arm64/amd64 hashes already present.Verification
All local, on linux/amd64 with Terraform 1.10.5. No plan or apply, and no real backends (
-backend=falsethroughout).origin/main(6b586cc),terraform/modules/build:terraform init -backend=false -lockfile=readonlythenterraform validategivesError: registry.terraform.io/hashicorp/external: the cached package ... does not match any of the checksums recorded in the dependency lock file. On this branch:Success! The configuration is valid.go test ./terraform/ -run TestLockFilesRecordEveryPlatformagainst main's lock files fails, listing every under-hashed provider (e.g.terraform/modules/build/.terraform.lock.hcl: registry.terraform.io/hashicorp/external (1 h1: hashes), want 4). It passes on this branch.terraform init -backend=false -lockfile=readonly -input=falseandterraform validate, with a throwawayTF_DATA_DIR. All 42 passed, and the worktree stayed clean, so no lock file was rewritten. For the 16 roots with atests/dir,terraform testalso passed: environments aws 9, azure 3, azure/ci-cd-permissions 2, gcp 3, gcp/ci-cd-permissions 13; iac azure-target 24; modules compute/aws/fargate 1, compute/aws/lambda 15, compute/azure/aks 9, database/azure 2, database/gcp 2, deployment-checks 4, monitoring/aws 5, monitoring/azure 1, monitoring/gcp 2, networking/aws 3 (counts are tests passed).actionlint .github/workflows/ci.yml: clean.go build ./... && go vet ./... && go vet -tags integration ./... && (cd tests/e2e && go vet -tags e2e ./...): OK.golangci-lint run ./terraform/...with and without--build-tags integration: 0 issues.go test -race -short -count=1 ./terraform/...andgo test -race -tags integration -count=1 ./terraform/...: ok.scripts/test-git-secrets-allowlist.sh: 183 PASS.Not verified locally: linux_arm64 and darwin. Their hashes come from
terraform providers lockagainst the public registry, and I had no arm64 or macOS runner to init on. CI's run of the edited workflow steps is also still to come.Conflicts to expect
Open PRs #1086, #1090, #1309 and #1312 also edit lock files (
database/aws,networking/aws,compute/azure/{aks,container-apps},compute/gcp/cloud-run). Whichever lands second should regenerate that lock file with the four-platform command above rather than hand-merge it. Once this lands,TestLockFilesRecordEveryPlatformand the readonly init will flag any lock file that loses a platform.🤖 Generated with Claude Code