In this episode, we're diving into the right way to store secrets in your project, especially when using things like API keys in tests and CI/CD pipelines. First, we recap why you should never commit secret keys to your codebase or even to environment files that are tracked in version control — doing so risks exposing these sensitive values.
We then move on to a hands-on example: adding a fake secret key to a config file, displaying it on a (test) dashboard, and writing a quick test to make sure it can be accessed. This helps lay the groundwork for understanding where secrets actually appear in your app during testing.
Next, we push our changes to GitHub Actions and deliberately break things to prove that not including the secret in our environment files causes the tests to fail. Once that's clear, we go through the process of fixing it the right way: adding a repository secret in GitHub, referencing that secret in the GitHub Actions workflow (using the secrets
context), and updating the test config to use it. The cool part is, this means your secret key is never present in your code or files — it's stored securely in GitHub and injected only when needed by your CI jobs.
Finally, we push the working setup, watch the tests pass again (with the secret injected properly), and talk about best practices: make sure secrets are only stored locally for development, always gitignore local env files, and use repository secrets for anything sensitive in CI like API keys. It's a must-do workflow for keeping your credentials safe, while still allowing full-featured automated testing!