Gabriel Radureau
9b545e6f8f
With the runner CA fix (#11) the iac workflow now runs far enough to apply, which exposed two provider problems: cloudflare drift — `cloudflare/cloudflare` floated on `~> 5` with no committed lock file, so CI pulled v5.21.1 where `cloudflare_account_token.policies[].resources` is a JSON string, not a map ("Incorrect attribute value type"). Fix: - pin to `~> 5.21` and commit a multi-platform `.terraform.lock.hcl` (linux_arm64 for the runner + darwin_arm64 for local); - `jsonencode(...)` the module's policy resources; - bind the cloudflare_token module to `cloudflare/cloudflare` explicitly (it was defaulting to `hashicorp/cloudflare`, pulling a redundant provider); - stop `.gitignore` from hiding the lock file (the old `.terraform.*` rule did). gitea provider TLS — it runs inside the dflook/terraform-apply container, which doesn't trust the homelab CA (only the ubuntu-latest-ca runner does), so it failed `x509: certificate signed by unknown authority` reaching gitea.arcodange.lab. Fix: feed it the homelab CA via the provider's `cacert_file` (TF_VAR_gitea_cacert_file -> the homelab.pem the workflow already materializes). Validated locally with `tofu validate` + provider-schema inspection (no prod calls). Complements #11. Out of scope (need a live run / operator): the OVH consumer-key scope, and the R2 bucket "not found" on refresh (a state reconcile). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Provisionne un utilisateur gitea "tofu_module_reader", autorisé à lire certains projets il est utilisé par la CI pour récupérer des blueprints terraform via sa clé ssh répertoriée dans vault.
configure les tokens ovh et cloudflare pour permettre aux autre projet de gérer des resources du cloud