dmarc-ing/terraform-provider-dmarcing
Watch
5
0
Fork
You've already forked terraform-provider-dmarcing
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

fix(release): read VAULT_ADDR from vars, not secrets #8

Merged
alice merged 1 commit from fix/release-vault-addr-var into main 2026-08-27 21:06:54 +00:00
Conversation 0 Commits 1 Files changed 1 +1 -1
gitea_admin commented 2026-08-27 21:05:26 +00:00
Owner
Copy link

Every release run since v0.1.0 has failed at the "Guard required secrets" step (~8s runtime each time) -- confirmed by checking configured secrets/vars via the API. Root cause: VAULT_ADDR is set at the org level as an Actions variable, but the workflow read it as secrets.VAULT_ADDR, which always resolves empty. Fixed here to read vars.VAULT_ADDR instead.

This alone will not make a release succeed yet -- two more things are still missing and need to be supplied by a human before the next tag push can complete: (1) GPG_PRIVATE_KEY / GPG_PASSPHRASE secrets (org or repo level) for signing the release -- not present anywhere currently; (2) the OpenBao KV entry at kv/ci/terraform-provider-dmarcing/boring-registry (aws_access_key_id, aws_secret_access_key, s3_bucket, s3_endpoint, s3_region) is empty -- the JWT auth role itself is correctly configured server-side, just the underlying secret data was never populated.

Every release run since v0.1.0 has failed at the "Guard required secrets" step (~8s runtime each time) -- confirmed by checking configured secrets/vars via the API. Root cause: VAULT_ADDR is set at the org level as an Actions *variable*, but the workflow read it as `secrets.VAULT_ADDR`, which always resolves empty. Fixed here to read `vars.VAULT_ADDR` instead. This alone will not make a release succeed yet -- two more things are still missing and need to be supplied by a human before the next tag push can complete: (1) GPG_PRIVATE_KEY / GPG_PASSPHRASE secrets (org or repo level) for signing the release -- not present anywhere currently; (2) the OpenBao KV entry at kv/ci/terraform-provider-dmarcing/boring-registry (aws_access_key_id, aws_secret_access_key, s3_bucket, s3_endpoint, s3_region) is empty -- the JWT auth role itself is correctly configured server-side, just the underlying secret data was never populated.
fix(release): read VAULT_ADDR from vars, not secrets
All checks were successful
Go lint / lint (pull_request) Successful in 2m34s
Details
25ac489358 
VAULT_ADDR is defined at the org level as an Actions variable, not a
secret. secrets.VAULT_ADDR always resolved empty, so every release run
failed at the required-secrets guard before OpenBao auth was ever
attempted.
alice merged commit 09e87234a7 into main 2026-08-27 21:06:54 +00:00
alice deleted branch fix/release-vault-addr-var 2026-08-27 21:06:54 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
dmarc-ing/terraform-provider-dmarcing!8
No description provided.