This repository demonstrates using GitHub Actions to deploy into either a staging or production environment.
Each deployment environment (i.e., staging or production) is managed as a Github Environment. Within each Github Environment, we store environment variables and environment secrets to be used during the deployment process. This demonstration repository only uses a single environment variable (MESSAGE) and environment secret (API_KEY).
When a push occurs to main (e.g. a PR is merged to main or a commit is pushed directly to main), a deployment to the staging environment will be triggered.
When a new Release occurs, a deployment to the production environment will be triggered.
Deployments can be manually triggered from within the Github Actions UI. This allows feature branches to be deployed to an environment outside of the standard git-flow cycle (i.e. first merging to main).
Important
Any user with WRITE permissions on the repo can trigger a deployment of any branch to any environment. This can be restricted with by appending a check of the github.actor within the if: clause of the manual deployment job and restricting write access to main (see this discussion for more details).
When manually dispatching a deployment, a user can deploy even if tests fail.
This will ensure that deployment occurs despite test failures (example):
Otherwise, the deployment will halt when tests fail (example):
