| name | manual-validation-harness |
| description | Use when validating a Coralogix terraform-provider bug fix end-to-end against a real Coralogix environment. Builds the provider locally, runs multi-step Terraform apply/plan scenarios to verify idempotency, and catches perpetual-diff regressions before merge. |
Manual end-to-end validation
Trigger: user wants to exercise a provider bug fix against a real env, post-build pre-merge.
Procedure:
make install from the PR branch (builds + installs to ~/.terraform.d/plugins/locally/debug/coralogix/1.5/<arch>).- Isolated workdir:
mkdir /tmp/<ticket>-test && cd $_.
- Project-local
terraformrc with dev_overrides for coralogix/coralogix pointing at the install dir above. export TF_CLI_CONFIG_FILE=$PWD/terraformrc.
- Multi-step scenarios: keep step files in
./steps/, cp steps/stepN.tf main.tf between runs. (Terraform reads every .tf in cwd → loose step files cause duplicate-resource errors.)
- Each step:
terraform apply -auto-approve, verify in UI, then terraform plan → expect No changes. (idempotency catches perpetual-diff regressions).
- Cleanup:
terraform destroy -auto-approve && rm -rf /tmp/<ticket>-test.
Gotchas:
- 403 from API = key/env mismatch, not a provider bug.
- "Provider development overrides are in effect" warning is expected.
- Don't write
.tf files via heredoc in chat — paste indentation breaks them. Use an editor or have Claude Write them.
Why: unit + acceptance tests catch regressions; manual validation gives the reviewer end-to-end confidence and exposes UI-layer behaviour the test suite can't observe.
