Problem
Projects like gocodealone-dns use top-level wfctl.yaml to pin plugins, then provider configs under infra/*.wfctl.yaml consume secrets through environment variables, for example:
workflow-plugin-cloudflare declares CLOUDFLARE_API_TOKEN
workflow-plugin-namecheap declares NAMECHEAP_API_USER, NAMECHEAP_API_KEY, NAMECHEAP_CLIENT_IP
infra/cloudflare.wfctl.yaml and infra/namecheap.wfctl.yaml reference those values as ${...}
Today, the operator has to know or manually inspect plugin manifests/docs and then run separate wfctl secrets set ... --scope org ... commands. wfctl secrets setup --plugin <name> helps for one plugin at a time, but there is no unified repo-level flow that starts from the project's pinned plugin config and tells the operator exactly which secrets are required.
Desired behavior
Add a unified wfctl path that can discover required secrets from the project configuration and guide setup. Possible shape:
wfctl secrets setup --manifest wfctl.yaml --scope org --org GoCodeAlone --visibility private
or:
wfctl secrets setup --plugins-from wfctl.yaml --config 'infra/*.wfctl.yaml'
The command should:
- Read pinned plugins from
wfctl.yaml / .wfctl-lock.yaml.
- Load each plugin's
required_secrets metadata.
- Optionally scan selected workflow config files for
${ENV_VAR} references.
- Present a deduplicated list of required secrets.
- Prompt/set missing secrets through the selected provider/scope.
- Make repo/env/org GitHub Actions secret setup easy without requiring an
app.yaml secrets provider when the project is primarily wfctl-manifest based.
Acceptance criteria
- A project with only
wfctl.yaml, .wfctl-lock.yaml, and infra/*.wfctl.yaml can run one wfctl secrets setup ... command and be guided through all required plugin secrets.
- Plugin metadata and config env references are both considered, with clear output explaining source/reason for each secret.
- Supports GitHub repo/env/org scopes consistently with existing
wfctl secrets set behavior.
- Does not print secret values.
- Works for
workflow-plugin-cloudflare and workflow-plugin-namecheap as concrete fixtures.
Context
This came up while enabling Cloudflare and Namecheap DNS imports in gocodealone-dns. The project already has plugin pins and provider configs, but the secret setup UX still requires manual knowledge of plugin-specific env names.
Problem
Projects like
gocodealone-dnsuse top-levelwfctl.yamlto pin plugins, then provider configs underinfra/*.wfctl.yamlconsume secrets through environment variables, for example:workflow-plugin-cloudflaredeclaresCLOUDFLARE_API_TOKENworkflow-plugin-namecheapdeclaresNAMECHEAP_API_USER,NAMECHEAP_API_KEY,NAMECHEAP_CLIENT_IPinfra/cloudflare.wfctl.yamlandinfra/namecheap.wfctl.yamlreference those values as${...}Today, the operator has to know or manually inspect plugin manifests/docs and then run separate
wfctl secrets set ... --scope org ...commands.wfctl secrets setup --plugin <name>helps for one plugin at a time, but there is no unified repo-level flow that starts from the project's pinned plugin config and tells the operator exactly which secrets are required.Desired behavior
Add a unified
wfctlpath that can discover required secrets from the project configuration and guide setup. Possible shape:or:
wfctl secrets setup --plugins-from wfctl.yaml --config 'infra/*.wfctl.yaml'The command should:
wfctl.yaml/.wfctl-lock.yaml.required_secretsmetadata.${ENV_VAR}references.app.yamlsecrets provider when the project is primarily wfctl-manifest based.Acceptance criteria
wfctl.yaml,.wfctl-lock.yaml, andinfra/*.wfctl.yamlcan run onewfctl secrets setup ...command and be guided through all required plugin secrets.wfctl secrets setbehavior.workflow-plugin-cloudflareandworkflow-plugin-namecheapas concrete fixtures.Context
This came up while enabling Cloudflare and Namecheap DNS imports in
gocodealone-dns. The project already has plugin pins and provider configs, but the secret setup UX still requires manual knowledge of plugin-specific env names.