Have you considered just rendering the yaml files using a template and a small script? then whenever you make changes to the workflow you do it to the template and rerender

Did you try to use

${GITHUB_REF##*/}

This should extract the branch part from “GITHUB_REF” env variable which is usually in form of “refs/heads/branch-name”.

Thank you @bomb-on and @ssboisen, I just took another look at the docs and found a syntax to set ENV vars that persist between steps:

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions#set-an-environment-variable-set-env

This is what I did to set the ENVIRONMENT variable automatically:

steps:
    - name: Set env to staging
      if: endsWith(github.ref, '/develop')
      run: |
        echo "::set-env name=ENVIRONMENT::staging"
    - name: Set env to production
      if: endsWith(github.ref, '/master')
      run: |
        echo "::set-env name=ENVIRONMENT::production"

It’s kind of a simple mapping between branches and environment names and works in this case as we have only 2. When you run it, it looks like this:

Bildschirmfoto 2019-12-03 um 20.16.19.png882×364 20.4 KB

See that the production step is skipped, as I was pushing to the “develop” branch. With this var set, everything else falls into place.

At the top of my workflow file I have the following now:

name: Build and deploy
on:
  push:
    branches:
    - develop
    - master

I am happy now as I have to maintain 1 workflow file only and don’t have to remember to run a script when I change something. Thank you again for supporting me with your ideas.

Hi @mklappir, I’m doing the same thing pretty much already, as I’m reading from github.ref, which is pretty much the same as GITHUB_REF. Extracting the part after the last slash is a neat trick, but the endsWith macro serves me just as well.

Extracting the current branch name was just part of the problem, but my main concern was how to map the branch name (develop, master) to the environment name (staging, production) and save that part in an environment variable that persists between steps. So I need:

• “develop” branch ➡️ export ENVIRONMENT=“staging”
• “master” branch ➡️ export ENVIRONMENT=“production”

I agree that in an ideal world, I would just rename the environments according to the branch name, but that would require a lot of work on other ends which I want to avoid, especially now that I have a solution that works for me.

If you use PowerShell then this should do the trick:

run: |
  echo "ENVIRONMENT=staging" | Out-File -FilePath $Env:GITHUB_ENV -Encoding utf8 -Append

In Windows cmd it should work like this:

run: |
  chcp 65001 > nul
  echo ENVIRONMENT=staging >> %GITHUB_ENV%

gitgub.ref_name and $GITHUB_REF_NAME has the information you need without having to use endsWith()

This is how I did it to get around updating the environment being deprecated.

jobs:
  setup-stage:
    outputs:
      env-name: ${{ steps.env-name.outputs.env }}
    runs-on: ubuntu-latest
    steps:
      - name: Setup Environment Name
        id: env-name
        run: echo "::set-output name=env::${{ fromJSON('{"main":"prod","develop":"dev"}')[github.ref_name] }}"
  build:
    needs: setup-stage
    runs-on: ubuntu-latest
    steps:
      - run: echo "Environment: ${{ needs.setup-stage.outputs.env-name }}"

FWIW, ref_name appears to be a recent addition. It was certainly not available at the time when endsWith was suggested.