Problem
GHA's environment: key on a job gates it behind required reviewers, deployment branch rules, and environment-scoped secrets. The framework's environments are logical labels in a promotion chain — generated deploy jobs don't use the GHA environment: attribute, so prod deployments have no approval gate at the GHA level even if the framework tracks env progression.
Proposed config
ci:
config:
deploys:
- name: app
workflow: .github/workflows/deploy-app.yaml
gha_environment: production # Emit 'environment: production' on the jobOr auto-derive from the top-level environments list when the name matches a GitHub Environment.
Impact
High for teams that need prod approval workflows. This is a hard gap — there's no workaround at the framework level; the user has to wrap the deploy callback in a separate workflow that has the GHA environment key.
Problem
GHA's
environment:key on a job gates it behind required reviewers, deployment branch rules, and environment-scoped secrets. The framework's environments are logical labels in a promotion chain — generated deploy jobs don't use the GHAenvironment:attribute, so prod deployments have no approval gate at the GHA level even if the framework tracks env progression.Proposed config
Or auto-derive from the top-level environments list when the name matches a GitHub Environment.
Impact
High for teams that need prod approval workflows. This is a hard gap — there's no workaround at the framework level; the user has to wrap the deploy callback in a separate workflow that has the GHA environment key.