Product Research around GitHub Actions- Environments
Issue purpose
What can we learn from GitHub Actions: Environments, environment protection rules and environment secrets (beta)
Why needed
The addition of environment protection rules and environment secrets enable separation of concerns between deployment and development to meet compliance and security requirements.
The required reviewers environment protection rule will automatically pause a job trying to deploy to the protected environment and notifies the reviewers.
Once approved, the job runs and is given secured access to the environment’s secrets. Also, the environments page includes a deployment log and information on the latest code change deployed to each environment.
Feature Comparison
Screenshots
Approving or rejecting a job
Examples
GitHub Actions: Manual triggers with workflow_dispatch
Manual triggers use the workflow_dispatch
keyword
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
tags:
description: 'Test scenario tags'
GitHub Actions Future Plans
Branch Filter for Environment Protection Rules - ability to specify a branch filter as an environment protection rule. Example: Specify workflows triggered from main branch are the only ones to access certain environment secrets. This way it can be combined with existing branch protection rules to only deploy code that’s been reviewed and merged to a specific branch like main.
Gaps (Not supported in GitLab
Users can set approvers for each environment
Users can also add environment-level secret (This is similar to "Environment Scope" in GitLab)
Someone kicked off a deployment pipeline, but it's waiting for approvals
Only eligible approvals can proceed the deployment. This action allows to inject environment-level secret into the job. i.e. this is the "A workflow job cannot access environment secrets until approval is granted by required approvers." part
Approvals history can be observed.