Last week GitHub released a feature I’ve wanted for a long time, configuration variables in GitHub Actions.
Today, while I was pairing with a coworker, I got an excuse to use configuration variables, which made what we were working on much more straightforward.
GitHub Actions has the concept of environments, which is super handy since we set up a new app to deploy to different environments.
GitHub environments offer various options, including requiring approvals from users before deploying to that environment, associating branches with that environment, and associating secrets and configuration variables with that environment.
In the past, I used secrets to store information like what S3 bucket I wanted to use for a particular environment. This worked great since it abstracted the knowledge of where to push files from the pipelines and let me change settings without touching the pipeline files.
What was challenging about this approach was that GitHub treated every secret as if it was a secret that needed to be removed from logs and never visible after setting it.
Today we used a configuration variable to store the S3 bucket, and we could see the value while looking at the environment. We could also see the value in the logs where it showed us the full path as we did an s3 copy.
This might not seem too important, but it was critical because I typed the wrong bucket name when setting the new variable. We wouldn’t have noticed if it had been a secret until we ran the pipeline and it failed. Instead we noticed before hand, quickly corrected the value, and watched out deploy succeed.
If you’d like to start using configuration variables in your pipelines check out the docs Creating configuration variables for an environment.
Dan Cook 