ci: update release app secret references
The release workflow needs to read GitHub App credentials from the verified canonical item using the dedicated target-vault service account. This updates the App ID and private-key field references and maps the action's expected token variable to the new repository secret.
The central audit verified the App and repository installation and compared the canonical fields with the prior verified destination. A validation-only dispatch at the final head successfully loaded both canonical references using the repository secret; the release job and downstream documentation deployment skipped. The validation job is restricted to manual dispatch on this branch. The original source private key was not compared byte-for-byte.
Validation: actionlint and formatting passed locally; the exact-head validation run was 42187453810. The release job and downstream documentation deployment skipped.
Related issue
None.
Compatibility
Not applicable to published packages; this changes release automation.
Validation and release checklist
- CI, actionlint and zizmor passed at
33025351f0de1abe9410e2155fc3ad6c28418b4f. - Exact-head validation loaded the canonical fields; the release job skipped. This checks field availability, not token minting. The central audit separately verified App identity and installation.
- The branch-specific preflight job and release guard are temporary and must be removed before any eventual merge, followed by safe validation of the resulting head. No merge is authorized.
- No package release or Changeset is required for this CI-only change.
Created with GPT-6.1 Terra in Codex.
[!NOTE]
Update release workflow secret references and add vault validation job
Updates credential loading in release.yml to use new service-account secret and GitHub App vault references. The release job is skipped for manual dispatches on the specified branch. A new validate_target_vault job runs on matching manual dispatches, loads the GitHub App ID and private key, and fails if either is empty.
- Workflow-level permissions are now an empty map; the release job declares its own
contents, id-token, and pull-requests write permissions
- Behavioral Change: workflow-level permissions default to none, so any job added later must declare its own permissions
Macroscope summarized 3302535.