How to access Environment Secrets with GitHub Actions?

3 min read.

This article aims to clear the confusion around the GitHub Repository Secrets and explain how to successfully use them in your pipelines for fun and profit!

Well, mostly for additional security and pipeline parameterization, really… But still – it’s a good piece of functionality to wrap your head around and implement in your daily work.

Problem

Table of Contents

When wanting to use Environment-specific secrets with GitHub Actions, the right sequence of steps is – in theory – quite clear. It goes somewhat like this:

Configure your environment
Add a secret to your environment
Map that environment to a deployment job in your GitHub Actions pipeline
Use the secret(s) in your pipeline like this ${{ secrets.mySecret }}

And it just work!

But in practice, it’s not always as easy – and when you google around, you may find out that other people are struggling with this as well.

So what do?

Background

I often start my own investigation into issues with GitHub Copilot these days. If it adequately solves my issue – it’s usually not worth blogging about.

But on this one, it sent me on a wild goose chase (as it has done a few times before), of making back-and-forth changes.

I’m not saying tweaking a YAML file one tiny change at a time and seeing if the build goes through ISN’T what I usually do – but at least I don’t just switch it back and forth between 2 non-functional states.

Well, usually I don’t. Anyway.

When you’re ready to give up on GitHub Copilot and start fixing the issue the old-fashioned way, you’ll probably come up with resources or guides somewhat like this:

Got this picture from a GitHub thread discussing Environment Secrets being broken, but I think it’s originally from StackOverflow. No matter – it’s misleading and incorrect in any case.

But that’s enough of that. Let’s take a crack at fixing this, shall we?

Reason / Investigation

Like I said, I already knew, or at least thought I knew, what to do. I set up the repository secrets (despite the busy screenshot above, the UI is very straightforward) and decided to add a task to my pipeline for replacing an entry in my project’s appsettings.json file. Namely, my key vault’s name.

For that, I needed to whip up some YAML. As usual, I decided to use GitHub Copilot to create it.

It tried to make me use sed, but just like the last time, it was absolutely unable to make it work. It had a lot of proposals, though – and of course, I got to read through a lot of documentation while I was it. And just like the last time, nor GitHub Copilot or me were able to deal with sed.

Perhaps not surprising – sed is a sophisticated tool for galaxy-brained individuals. And all the processing power that Microsoft has combined with whatever experience I’ve gathered is not enough to make it work.

Anyway – it did make me just give up and use PowerShell… Since unlike sed, it does work.

      - name: Replace placeholder values
        shell: pwsh
        run: |
          # my working directory is already the solution folder
          $path = 'appsettings.json'
          $content = Get-Content -Path $path -Raw
          $content = $content -replace '\$kvname\$', '${{ secrets.KEYVAULT_NAME }}'
          $content | Set-Content -Path $path

And now we can add this to the pipeline’s YAML file… But where? And what exactly do we need to make it work?

Solution

Let’s put it all together, shall we?

You will see a lot of discussions online about Environment Secrets not working on GitHub. I’m sure this has been the case before, but I assume some of the more recent complaints are just people trying (and failing) to use sed, and then reading the logs and not seeing the secrets (as they shouldn’t) or something along those lines.

But take a look at the setup below for reference – it is for an environment called “Production”, and the secret is called “KEYVAULT_NAME”.

You also need to access these secrets in a deploy job, and map the environment to the job properly – using one of the following syntaxes:

deploy:
  environment: 'Production'

Or, alternatively:

deploy:
  environment:
    name: 'Production'

Like shown below:

And with that, our pipeline should function just fine! The output of your task should look somewhat like below:

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)