Multiple Azure Subs One Github Action

One of the benefits of working for an Azure MSP is that no two days are the same. You are constantly presented with different challenges to solve. It’s a lot of fun! I decided to write about how we solved one particular challenge below.

The Challenge

You’re working on a project that requires you to automatically deploy resources to Azure when a new branch is created in your GitHub repository. In this use case, you’re working with a company that is creating Azure Functions to bridge the gap between Azure and their software platform. Every time they want to test some tweaks or changes, a new branch is created. To support this testing, they need to create an Azure Function and a few other supporting resources. This can be time consuming when done manually. This is where GitHub Actions Workflows or Azure DevOps Pipelines come in. To complicate matters, you are following some best practice advice that you should keep your Production, Development, and Test environments in separate subscriptions.

In this article, we will focus on how to create a workflow in GitHub Actions that logs into the correct Azure subscription, specifically the Dev or Test subscriptions, based on a branch naming convention. The naming convention states that they must use ‘dev’ or ‘test’ in their branch names so that we can ensure that the resources are created in the correct Azure subscriptions.

If you’re new to GitHub Actions or Azure DevOps Pipelines, click the links to find out more.

The Solution

Firstly, a big thank you to Sam Smith who answered a query on Twitter about how to reference the branch name correctly in a conditional step in the workflow.

In order for the workflow to successfully log in to the Azure subscriptions, you will need to make sure that you have created a Service Principal with the appropriate permissions. Once the Service Principal has been created you can add the details to a repository secret on GitHub. You can find out more about how to create this Service Principal on the ‘Azure/Login’ GitHub repo. Once created, you secrets might look like the below.

You can see the workflow YAML file below. I’ve included some annotations to help if you’re unfamilar with workflow files in GitHub Actions.

name: New Branch Trigger

on:
  create: # Triggers on the creation of a new branch (or release).

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest # Hosted build agent that our new action runs on.

    steps:
      - uses: actions/checkout@v2 # Checks out our GitHub repo.

      - name: Git default branch name
        run: echo $GITHUB_REF

      - name: Git branch name
        id: git-branch-name
        uses: EthanSK/git-branch-name-action@v1 # Action to grab the current branch name.

      - name: Echo the branch name
        run: echo "Branch name is ${GIT_BRANCH_NAME}"

      - name: Login via Az module (DEV)
        uses: azure/login@v1 # The name of the action we are using.
        with:
          creds: ${{secrets.AZURE_CREDENTIALS_DEV}} # Reference to the secret we created earlier.
          enable-AzPSSession: true 
        if: contains(github.ref, 'dev') # Conditional check. 
        # Checks if the Github branch contains 'dev'. This step will only run if this is TRUE.

      - name: Login via Az module (TEST)
        uses: azure/login@v1
        with:
          creds: ${{secrets.AZURE_CREDENTIALS_TEST}}
          enable-AzPSSession: true 
        if: contains(github.ref, 'test') # Conditional check. 
        # Checks if the Github branch contains 'test'. This step will only run if this is TRUE.

In addition to the ‘Azure/Login’ action that I mentioned above, I am also using an action called ‘git-branch-name-action’. It grabs the current branch name and uses it to create an environment variable. I like this action as it just grabs the branch name whereas the default '$GITHUB_REF' environment variable outputs it in the format ‘refs/heads/branchname’. This is useful as I want to use the branch name variable in the naming of the Azure resources this workflow goes on to create. You can find out more about this action in the GitHub Marketplace here. My thanks to creator Ethan Sarif-Kattan!

I’ve included some screenshots of the workflow running and triggering different steps depending on the branch name.

Workflow run - Dev Branch

As you can see in the image below, the branch in this run contained ‘dev’ in the name which meant it triggered the ‘Login via Az Module (Dev)' step.

Workflow run - Test Branch

As you can see in the image below, the branch in this run contained ‘test’ in the name which meant it triggered the ‘Login via Az Module (Test)' step.

If you’ve been following along, you now have a GitHub Action workflow that will be triggered when you create a new branch in your repository. It will also deploy your resources to the correct Azure subscription thanks to the conditional Azure login steps. Check back in the coming weeks for articles where I expand on my use of this workflow.

---

PSA: Remember , it’s NOT a good idea to experiment on a production environment. Please make sure you test any recommendations you read online in a Dev or Test environment before going to production.

Thank you for taking the time to read this article. I hope you found it useful. If you did, please feel free to share on your social media and tag me. You can find my social media handles above or to the left, depending on what device you are reading this on.

---