feat: add godaddy-tofu provider and DNS A records #436

Merged
ldraney merged 7 commits from feat/dns-terraform-provider into main 2026-06-15 12:44:06 +00:00
Owner

Closes #435

Summary

  • Brings palinks.app and landscaping-assistant.app DNS records under Tofu management using the custom godaddy-tofu provider
  • Both A records point to the Hetzner edge VPS at 178.156.129.142 (Caddy + Tailscale reverse proxy)
  • Adds GoDaddy API credentials to the secrets pipeline (Makefile TF_SECRET_VARS, secrets.auto.tfvars.example)

Discovered Scope

None

Terraform Changes

Provider is not in any public registry -- uses dev_overrides in ~/.terraformrc pointing to the go install output of godaddy-tofu. tofu plan cannot be run in CI without the provider binary installed locally.

  • tofu fmt passed
  • tofu validate passed (pre-existing module-not-installed errors only; no errors from new code)

README Impact

  • README roadmap updated (or N/A)

Review Checklist

  • Review-fix loop passed (clean review, zero issues)
  • User approved merge

Changes

  • terraform/versions.tf -- added godaddy to required_providers with source ldraney/godaddy
  • terraform/providers.tf -- added provider "godaddy" block using var.godaddy_api_key and var.godaddy_api_secret
  • terraform/dns.tf (new) -- two godaddy_dns_record resources: palinks_a and landscaping_assistant_a, both A records pointing to 178.156.129.142 with TTL 600
  • terraform/variables.tf -- added godaddy_api_key and godaddy_api_secret variables (both sensitive)
  • terraform/secrets.auto.tfvars.example -- added GoDaddy credential placeholders
  • Makefile -- added godaddy_api_key godaddy_api_secret to TF_SECRET_VARS for Salt pillar rendering

Test Plan

  • Add GoDaddy API credentials to Salt pillar and run make secrets to render secrets.auto.tfvars
  • Configure dev_overrides in ~/.terraformrc pointing to go install output of godaddy-tofu
  • Run cd terraform && tofu plan -- expect 2 new godaddy_dns_record resources
  • Run tofu apply -- records created in GoDaddy DNS
  • Verify with dig palinks.app and dig landscaping-assistant.app -- both resolve to 178.156.129.142
Closes #435 ## Summary - Brings palinks.app and landscaping-assistant.app DNS records under Tofu management using the custom godaddy-tofu provider - Both A records point to the Hetzner edge VPS at 178.156.129.142 (Caddy + Tailscale reverse proxy) - Adds GoDaddy API credentials to the secrets pipeline (Makefile TF_SECRET_VARS, secrets.auto.tfvars.example) ## Discovered Scope None ## Terraform Changes Provider is not in any public registry -- uses `dev_overrides` in `~/.terraformrc` pointing to the `go install` output of godaddy-tofu. `tofu plan` cannot be run in CI without the provider binary installed locally. - [x] `tofu fmt` passed - [x] `tofu validate` passed (pre-existing module-not-installed errors only; no errors from new code) ## README Impact - [ ] README roadmap updated (or N/A) ## Review Checklist - [ ] Review-fix loop passed (clean review, zero issues) - [ ] User approved merge ## Related Notes - Provider repo: ldraney/godaddy-tofu - Issue: ldraney/pal-e-platform#435 ## Changes - `terraform/versions.tf` -- added `godaddy` to `required_providers` with source `ldraney/godaddy` - `terraform/providers.tf` -- added `provider "godaddy"` block using `var.godaddy_api_key` and `var.godaddy_api_secret` - `terraform/dns.tf` (new) -- two `godaddy_dns_record` resources: `palinks_a` and `landscaping_assistant_a`, both A records pointing to 178.156.129.142 with TTL 600 - `terraform/variables.tf` -- added `godaddy_api_key` and `godaddy_api_secret` variables (both sensitive) - `terraform/secrets.auto.tfvars.example` -- added GoDaddy credential placeholders - `Makefile` -- added `godaddy_api_key godaddy_api_secret` to `TF_SECRET_VARS` for Salt pillar rendering ## Test Plan - [ ] Add GoDaddy API credentials to Salt pillar and run `make secrets` to render `secrets.auto.tfvars` - [ ] Configure `dev_overrides` in `~/.terraformrc` pointing to `go install` output of godaddy-tofu - [ ] Run `cd terraform && tofu plan` -- expect 2 new `godaddy_dns_record` resources - [ ] Run `tofu apply` -- records created in GoDaddy DNS - [ ] Verify with `dig palinks.app` and `dig landscaping-assistant.app` -- both resolve to 178.156.129.142
feat: add godaddy-tofu provider and DNS A records for public domains
Some checks failed
ci/woodpecker/push/terraform Pipeline was successful
ci/woodpecker/pr/terraform Pipeline failed
52b508c2d8
Brings palinks.app and landscaping-assistant.app DNS records under Tofu
management using the custom godaddy-tofu provider. Both A records point
to the Hetzner edge VPS at 178.156.129.142.

Closes ldraney/pal-e-platform#435

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Author
Owner

PR #436 Review

DOMAIN REVIEW

Tech stack: Terraform/OpenTofu (HCL), Makefile

This PR integrates the custom godaddy-tofu provider into the pal-e-platform Terraform configuration, adding two DNS A records for palinks.app and landscaping-assistant.app. Six files changed, 45 additions, 0 deletions. Scope is tight and well-bounded.

Provider registration (versions.tf)

  • Source ldraney/godaddy matches the provider's main.go address (registry.terraform.io/ldraney/godaddy). Correct.
  • No version constraint specified. Acceptable because the provider uses dev_overrides (local binary, not a registry download). The PR body documents this correctly.

Provider block (providers.tf)

  • Attributes api_key and api_secret match the provider schema in provider.go exactly. Both are passed from sensitive variables. Correct.

DNS resources (dns.tf)

  • Two godaddy_dns_record resources using attributes domain, type, name, data, ttl. All match the resource schema in resource_dns_record.go.
  • TTL 600 matches the provider's default. Explicit is better than implicit here -- good.
  • Both A records point to 178.156.129.142 (Hetzner edge VPS). This IP is hardcoded rather than referenced from the hcloud module output. This is consistent with how the IP is documented across godaddy-tofu/docs/ but is a cross-module coupling risk (see NITS).

Variables (variables.tf)

  • Both godaddy_api_key and godaddy_api_secret are typed string, marked sensitive = true, and have descriptions. Follows the existing variable pattern used by other providers (hcloud, minio, tailscale).

Secrets pipeline (Makefile, secrets.auto.tfvars.example)

  • TF_SECRET_VARS updated with both credential names. Insertion point is alphabetically reasonable (after hetzner, before telegram).
  • Example file includes CHANGEME placeholders with source comments pointing to GoDaddy Developer Portal. Consistent with existing entries.

Terraform style compliance

  • tofu fmt passed per PR body. Indentation and alignment in the diff are consistent with existing files.
  • tofu validate passed (pre-existing module-not-installed warnings only).

BLOCKERS

None.

  • No secrets or credentials in code -- credentials flow through sensitive variables and Salt pillar.
  • No unvalidated user input -- this is infrastructure declaration, not application code.
  • No DRY violations -- each resource is unique (different domains).
  • Test plan is appropriate for IaC: manual tofu plan / tofu apply / dig verification. Automated testing is not feasible without the provider binary in CI (documented limitation).

NITS

  1. Hardcoded IP address in dns.tf: Both records hardcode 178.156.129.142. If the Hetzner edge module outputs this IP (e.g., module.edge.ipv4_address), a cross-reference would eliminate drift risk if the edge node is ever reprovisioned. Current approach is consistent with existing documentation, so this is non-blocking.

  2. No version constraint on godaddy provider: When the provider eventually reaches a registry or stable versioning, adding version = "~> 0.1" (or similar) would prevent unexpected breakage. Non-blocking while using dev_overrides.

  3. Comment style in variables.tf: GoDaddy section uses # --- GoDaddy DNS --- while the secrets example file uses Unicode box-drawing characters (---). Minor inconsistency with the rest of variables.tf which uses the same # --- style, so this is actually correct for that file. No action needed.

SOP COMPLIANCE

  • PR body has Summary section
  • PR body has Changes section with per-file descriptions
  • PR body has Test Plan with concrete verification steps
  • PR body has Related section linking to provider repo and issue
  • PR body references parent issue (Closes #435)
  • No secrets, .env files, or credentials committed
  • No unnecessary file changes -- all 6 files are directly related to the task
  • tofu fmt and tofu validate passed
  • Sensitive variables marked sensitive = true
  • Secrets pipeline updated (Makefile + example file)

PROCESS OBSERVATIONS

  • Deployment frequency: This PR enables DNS-as-code for two domains, converting a manual GoDaddy console operation into a repeatable tofu apply. Positive impact on deployment frequency for domain changes.
  • Change failure risk: Low. DNS A records are idempotent -- applying the same record twice is a no-op. The dev_overrides requirement means CI cannot validate plans, which is an accepted tradeoff documented in the PR body.
  • Documentation: The godaddy-tofu provider repo has thorough documentation (architecture, deployment, auth, conventions). The PR body itself is well-structured with clear test steps.
  • Dependency chain: This PR is the integration point between godaddy-tofu (provider) and pal-e-platform (consumer). The next steps in the public ingress chain are Caddy configuration (#425, #434).

VERDICT: APPROVED

## PR #436 Review ### DOMAIN REVIEW **Tech stack: Terraform/OpenTofu (HCL), Makefile** This PR integrates the custom `godaddy-tofu` provider into the pal-e-platform Terraform configuration, adding two DNS A records for `palinks.app` and `landscaping-assistant.app`. Six files changed, 45 additions, 0 deletions. Scope is tight and well-bounded. **Provider registration (`versions.tf`)** - Source `ldraney/godaddy` matches the provider's `main.go` address (`registry.terraform.io/ldraney/godaddy`). Correct. - No version constraint specified. Acceptable because the provider uses `dev_overrides` (local binary, not a registry download). The PR body documents this correctly. **Provider block (`providers.tf`)** - Attributes `api_key` and `api_secret` match the provider schema in `provider.go` exactly. Both are passed from sensitive variables. Correct. **DNS resources (`dns.tf`)** - Two `godaddy_dns_record` resources using attributes `domain`, `type`, `name`, `data`, `ttl`. All match the resource schema in `resource_dns_record.go`. - TTL 600 matches the provider's default. Explicit is better than implicit here -- good. - Both A records point to `178.156.129.142` (Hetzner edge VPS). This IP is hardcoded rather than referenced from the `hcloud` module output. This is consistent with how the IP is documented across `godaddy-tofu/docs/` but is a cross-module coupling risk (see NITS). **Variables (`variables.tf`)** - Both `godaddy_api_key` and `godaddy_api_secret` are typed `string`, marked `sensitive = true`, and have descriptions. Follows the existing variable pattern used by other providers (hcloud, minio, tailscale). **Secrets pipeline (`Makefile`, `secrets.auto.tfvars.example`)** - `TF_SECRET_VARS` updated with both credential names. Insertion point is alphabetically reasonable (after hetzner, before telegram). - Example file includes `CHANGEME` placeholders with source comments pointing to GoDaddy Developer Portal. Consistent with existing entries. **Terraform style compliance** - `tofu fmt` passed per PR body. Indentation and alignment in the diff are consistent with existing files. - `tofu validate` passed (pre-existing module-not-installed warnings only). ### BLOCKERS None. - No secrets or credentials in code -- credentials flow through sensitive variables and Salt pillar. - No unvalidated user input -- this is infrastructure declaration, not application code. - No DRY violations -- each resource is unique (different domains). - Test plan is appropriate for IaC: manual `tofu plan` / `tofu apply` / `dig` verification. Automated testing is not feasible without the provider binary in CI (documented limitation). ### NITS 1. **Hardcoded IP address in `dns.tf`**: Both records hardcode `178.156.129.142`. If the Hetzner edge module outputs this IP (e.g., `module.edge.ipv4_address`), a cross-reference would eliminate drift risk if the edge node is ever reprovisioned. Current approach is consistent with existing documentation, so this is non-blocking. 2. **No version constraint on godaddy provider**: When the provider eventually reaches a registry or stable versioning, adding `version = "~> 0.1"` (or similar) would prevent unexpected breakage. Non-blocking while using `dev_overrides`. 3. **Comment style in `variables.tf`**: GoDaddy section uses `# --- GoDaddy DNS ---` while the secrets example file uses Unicode box-drawing characters (`---`). Minor inconsistency with the rest of `variables.tf` which uses the same `# ---` style, so this is actually correct for that file. No action needed. ### SOP COMPLIANCE - [x] PR body has Summary section - [x] PR body has Changes section with per-file descriptions - [x] PR body has Test Plan with concrete verification steps - [x] PR body has Related section linking to provider repo and issue - [x] PR body references parent issue (`Closes #435`) - [x] No secrets, `.env` files, or credentials committed - [x] No unnecessary file changes -- all 6 files are directly related to the task - [x] `tofu fmt` and `tofu validate` passed - [x] Sensitive variables marked `sensitive = true` - [x] Secrets pipeline updated (Makefile + example file) ### PROCESS OBSERVATIONS - **Deployment frequency**: This PR enables DNS-as-code for two domains, converting a manual GoDaddy console operation into a repeatable `tofu apply`. Positive impact on deployment frequency for domain changes. - **Change failure risk**: Low. DNS A records are idempotent -- applying the same record twice is a no-op. The `dev_overrides` requirement means CI cannot validate plans, which is an accepted tradeoff documented in the PR body. - **Documentation**: The godaddy-tofu provider repo has thorough documentation (architecture, deployment, auth, conventions). The PR body itself is well-structured with clear test steps. - **Dependency chain**: This PR is the integration point between `godaddy-tofu` (provider) and `pal-e-platform` (consumer). The next steps in the public ingress chain are Caddy configuration (#425, #434). ### VERDICT: APPROVED
Author
Owner

PR #436 Review

DOMAIN REVIEW

Stack: Terraform/OpenTofu (HCL), Makefile, secrets pipeline integration.

Terraform correctness -- versions.tf:
The godaddy provider entry omits a version constraint. Every other provider in required_providers pins a version (~> 2.36, ~> 2.17, ~> 0.28, ~> 3.5, ~> 1.49). This is intentional and acceptable here because the provider uses dev_overrides (not a registry), so there is no version to resolve. A comment explaining this would help future readers -- see nit below.

Terraform correctness -- dns.tf:
Resource syntax is correct. godaddy_dns_record matches the resource type declared in the godaddy-tofu provider (resource_dns_record.go). Attributes domain, type, name, data, ttl all match the provider schema from godaddy-tofu/CLAUDE.md. TTL 600 (10 min) is reasonable for A records.

Terraform correctness -- providers.tf:
Provider block uses api_key and api_secret attributes, consistent with the godaddy-tofu provider schema. References var.godaddy_api_key and var.godaddy_api_secret -- both declared in variables.tf with sensitive = true.

Terraform correctness -- variables.tf:
Both variables follow the existing pattern: description, type = string, sensitive = true. Variable naming uses godaddy_ prefix, consistent with the tailscale_, hetzner_, woodpecker_ prefix convention in the file.

Secrets pipeline -- Makefile:
godaddy_api_key godaddy_api_secret added to TF_SECRET_VARS. This means make tofu-secrets will render them from Salt pillar into secrets.auto.tfvars. The placement is correct (after hetzner_api_token edge_ssh_public_key, before telegram_landscaping_chat_id).

Secrets pipeline -- secrets.auto.tfvars.example:
Placeholders added with helpful comment pointing to GoDaddy Developer Portal. Follows the existing CHANGEME pattern. Placement between Telegram and Hetzner sections is fine.

Hardcoded IP (178.156.129.142):
Both DNS records hardcode the edge VPS IP. The Hetzner edge module at terraform/modules/hetzner-edge/outputs.tf exposes server_ipv4 as a module output. Ideally, dns.tf would reference module.hetzner_edge.server_ipv4 instead of hardcoding 178.156.129.142. However, this creates a dependency ordering concern: if the edge VPS is destroyed and recreated with a new IP, the DNS records would update automatically -- which is actually desirable behavior. See nit below.

BLOCKERS

None. No security issues, no missing test coverage (declarative Terraform does not require unit tests for resource declarations), no credentials in code, no DRY violations in auth paths.

NITS

  1. Hardcoded IP vs module reference (dns.tf): Consider replacing "178.156.129.142" with a local or a reference to the hetzner-edge module output:

    locals {
      edge_vps_ip = module.hetzner_edge.server_ipv4
    }
    

    Then use local.edge_vps_ip in both records. This eliminates the hardcoded value and ensures DNS records auto-update if the edge VPS IP changes. If the ordering concern is real (DNS must exist before edge module), a comment explaining why the IP is hardcoded would suffice.

  2. Missing version comment (versions.tf): Add a comment explaining why no version constraint exists:

    godaddy = {
      source = "ldraney/godaddy"
      # No version constraint -- uses dev_overrides, not a registry
    }
    
  3. Missing telegram_landscaping_chat_id in secrets.auto.tfvars.example: Pre-existing gap -- this variable is in TF_SECRET_VARS and variables.tf but not in the example file. Not introduced by this PR, but worth noting.

  4. Missing OIDC secrets in secrets.auto.tfvars.example: grafana_oidc_client_secret, admin_oidc_client_secret, admin_auth_secret, forgejo_oidc_client_secret, harbor_oidc_client_secret are all in TF_SECRET_VARS and variables.tf but missing from the example file. Also pre-existing -- not introduced by this PR.

SOP COMPLIANCE

  • PR body has Summary, Changes, Test Plan, Related sections
  • tofu fmt passed (stated in PR body)
  • tofu validate passed (stated in PR body)
  • No secrets, .env files, or credentials committed
  • No unnecessary file changes -- all 6 files are directly related to adding the provider and DNS records
  • Commit messages are descriptive
  • Variables marked sensitive = true
  • Secrets pipeline integration (Makefile + example file) included
  • README roadmap updated (PR body notes this is unchecked -- non-blocking)

PROCESS OBSERVATIONS

  • Blast radius: Zero risk to existing resources. All changes are additive -- new provider, new resources, new variables. No modifications to existing provider configs or resources.
  • CI limitation: tofu plan cannot run in CI without the godaddy-tofu provider binary installed. This is a known limitation documented in the PR body. Consider adding the provider build step to CI once the provider is stable.
  • Deployment frequency: This is the final step in the public domain ingress chain (provider -> DNS config -> Caddy config). Issues #425 and #434 (Caddy configuration) are still open and depend on this being merged first.
  • Documentation: The docs/hetzner-edge.md file already documents the DNS A records for these domains. If the hardcoded IP is kept, ensure docs/hetzner-edge.md stays in sync.

VERDICT: APPROVED

## PR #436 Review ### DOMAIN REVIEW **Stack:** Terraform/OpenTofu (HCL), Makefile, secrets pipeline integration. **Terraform correctness -- versions.tf:** The `godaddy` provider entry omits a `version` constraint. Every other provider in `required_providers` pins a version (`~> 2.36`, `~> 2.17`, `~> 0.28`, `~> 3.5`, `~> 1.49`). This is intentional and acceptable here because the provider uses `dev_overrides` (not a registry), so there is no version to resolve. A comment explaining this would help future readers -- see nit below. **Terraform correctness -- dns.tf:** Resource syntax is correct. `godaddy_dns_record` matches the resource type declared in the godaddy-tofu provider (`resource_dns_record.go`). Attributes `domain`, `type`, `name`, `data`, `ttl` all match the provider schema from `godaddy-tofu/CLAUDE.md`. TTL 600 (10 min) is reasonable for A records. **Terraform correctness -- providers.tf:** Provider block uses `api_key` and `api_secret` attributes, consistent with the godaddy-tofu provider schema. References `var.godaddy_api_key` and `var.godaddy_api_secret` -- both declared in variables.tf with `sensitive = true`. **Terraform correctness -- variables.tf:** Both variables follow the existing pattern: `description`, `type = string`, `sensitive = true`. Variable naming uses `godaddy_` prefix, consistent with the `tailscale_`, `hetzner_`, `woodpecker_` prefix convention in the file. **Secrets pipeline -- Makefile:** `godaddy_api_key godaddy_api_secret` added to `TF_SECRET_VARS`. This means `make tofu-secrets` will render them from Salt pillar into `secrets.auto.tfvars`. The placement is correct (after `hetzner_api_token edge_ssh_public_key`, before `telegram_landscaping_chat_id`). **Secrets pipeline -- secrets.auto.tfvars.example:** Placeholders added with helpful comment pointing to GoDaddy Developer Portal. Follows the existing `CHANGEME` pattern. Placement between Telegram and Hetzner sections is fine. **Hardcoded IP (178.156.129.142):** Both DNS records hardcode the edge VPS IP. The Hetzner edge module at `terraform/modules/hetzner-edge/outputs.tf` exposes `server_ipv4` as a module output. Ideally, `dns.tf` would reference `module.hetzner_edge.server_ipv4` instead of hardcoding `178.156.129.142`. However, this creates a dependency ordering concern: if the edge VPS is destroyed and recreated with a new IP, the DNS records would update automatically -- which is actually desirable behavior. See nit below. ### BLOCKERS None. No security issues, no missing test coverage (declarative Terraform does not require unit tests for resource declarations), no credentials in code, no DRY violations in auth paths. ### NITS 1. **Hardcoded IP vs module reference (dns.tf):** Consider replacing `"178.156.129.142"` with a local or a reference to the hetzner-edge module output: ```hcl locals { edge_vps_ip = module.hetzner_edge.server_ipv4 } ``` Then use `local.edge_vps_ip` in both records. This eliminates the hardcoded value and ensures DNS records auto-update if the edge VPS IP changes. If the ordering concern is real (DNS must exist before edge module), a comment explaining why the IP is hardcoded would suffice. 2. **Missing version comment (versions.tf):** Add a comment explaining why no version constraint exists: ```hcl godaddy = { source = "ldraney/godaddy" # No version constraint -- uses dev_overrides, not a registry } ``` 3. **Missing `telegram_landscaping_chat_id` in secrets.auto.tfvars.example:** Pre-existing gap -- this variable is in `TF_SECRET_VARS` and `variables.tf` but not in the example file. Not introduced by this PR, but worth noting. 4. **Missing OIDC secrets in secrets.auto.tfvars.example:** `grafana_oidc_client_secret`, `admin_oidc_client_secret`, `admin_auth_secret`, `forgejo_oidc_client_secret`, `harbor_oidc_client_secret` are all in `TF_SECRET_VARS` and `variables.tf` but missing from the example file. Also pre-existing -- not introduced by this PR. ### SOP COMPLIANCE - [x] PR body has Summary, Changes, Test Plan, Related sections - [x] `tofu fmt` passed (stated in PR body) - [x] `tofu validate` passed (stated in PR body) - [x] No secrets, .env files, or credentials committed - [x] No unnecessary file changes -- all 6 files are directly related to adding the provider and DNS records - [x] Commit messages are descriptive - [x] Variables marked `sensitive = true` - [x] Secrets pipeline integration (Makefile + example file) included - [ ] README roadmap updated (PR body notes this is unchecked -- non-blocking) ### PROCESS OBSERVATIONS - **Blast radius:** Zero risk to existing resources. All changes are additive -- new provider, new resources, new variables. No modifications to existing provider configs or resources. - **CI limitation:** `tofu plan` cannot run in CI without the godaddy-tofu provider binary installed. This is a known limitation documented in the PR body. Consider adding the provider build step to CI once the provider is stable. - **Deployment frequency:** This is the final step in the public domain ingress chain (provider -> DNS config -> Caddy config). Issues #425 and #434 (Caddy configuration) are still open and depend on this being merged first. - **Documentation:** The `docs/hetzner-edge.md` file already documents the DNS A records for these domains. If the hardcoded IP is kept, ensure `docs/hetzner-edge.md` stays in sync. ### VERDICT: APPROVED
chore: fix DNS terraform nits from PR #436 review (#438)
Some checks failed
ci/woodpecker/push/terraform Pipeline was successful
ci/woodpecker/pr/terraform Pipeline failed
ci/woodpecker/manual/terraform Pipeline was successful
ci/woodpecker/manual/ruby-arch Pipeline was successful
176765b167
ci: trigger PR pipeline with dev_overrides fix
Some checks failed
ci/woodpecker/push/terraform Pipeline was successful
ci/woodpecker/pr/terraform Pipeline failed
00fa84ce2f
ci: use filesystem_mirror for godaddy-tofu provider in CI
Some checks failed
ci/woodpecker/push/terraform Pipeline was successful
ci/woodpecker/pr/terraform Pipeline failed
d4268c9559
dev_overrides doesn't work with tofu init — init still tries to resolve
the provider from the registry and hard-fails. filesystem_mirror builds
the provider binary from source and places it in a local mirror so tofu
init finds it without hitting any registry.

- Add build-godaddy-provider step (golang:1.26, clones and builds)
- Configure filesystem_mirror in validate, plan, and apply steps
- Add version = "0.1.0" to required_providers for mirror resolution
- Wire depends_on so tofu steps wait for the build

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ci: add sleep + retry to build-godaddy-provider clone step
Some checks failed
ci/woodpecker/push/terraform Pipeline was successful
ci/woodpecker/pr/terraform Pipeline failed
9361e5d89f
Matches the clone step's sleep 2 pattern — k8s DNS needs a moment
after container startup before service names resolve.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ci: fix terraformrc heredoc to expand $CI_WORKSPACE
Some checks failed
ci/woodpecker/push/terraform Pipeline was successful
ci/woodpecker/pr/terraform Pipeline failed
df73a7b9a0
Single-quoted heredoc (<<'EOF') prevented shell expansion, so
$CI_WORKSPACE was written literally instead of resolved. Switch
to unquoted heredoc (<<EOF) so the shell expands the env var.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ci: build godaddy provider with CGO_ENABLED=0 for Alpine compat
All checks were successful
ci/woodpecker/push/terraform Pipeline was successful
ci/woodpecker/pr/terraform Pipeline was successful
ci/woodpecker/pull_request_closed/terraform Pipeline was successful
62b8a2f6ca
The provider binary is built in golang:1.26 (Debian/glibc) but executed
in opentofu:1.9 (Alpine/musl). Dynamic linking causes "no such file or
directory" because the glibc dynamic linker path doesn't exist in Alpine.
Static build with CGO_ENABLED=0 fixes this.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ldraney deleted branch feat/dns-terraform-provider 2026-06-15 12:44:06 +00:00
Sign in to join this conversation.
No description provided.