11

When running Github actions on a self hosted runner machine, how do I access existing custom environment variables that have been set on the machine, in my Github action .yaml script?

I have set those variables and restarted the runner virtual machine several times, but they are not accessible using the $VAR syntax in my script.

prmph
  • 7,616
  • 11
  • 37
  • 46
  • Where have you set those variables? And have you restarted the runner after setting the variables? – jessehouwing Feb 18 '22 at 19:51
  • @jessehouwing Yes, that is elementary, the runner EC2 virtual machine has been restarted several times. – prmph Feb 18 '22 at 19:53
  • Does the `run: env` command print the $VAR on the console when you execute it inside your self-hosted runner? (Workflow [example](https://github.com/GuillaumeFalourd/poc-github-actions/blob/main/.github/workflows/46-print-env.yml) and [run](https://github.com/GuillaumeFalourd/poc-github-actions/runs/5253088347?check_suite_focus=true) on github runners). If yes, did you try using `${{ env.VAR }}`? – GuiFalourd Feb 18 '22 at 20:15
  • 1
    @GuiFalourd `run: env` does not show all the env variables. `${{ env.VAR }}` also does not access it – prmph Feb 18 '22 at 22:02
  • How did you set the environment variable? – jessehouwing Feb 18 '22 at 22:32
  • @jessehouwing in /etc/environment file – prmph Feb 19 '22 at 00:04
  • 1
    Have you tried setting them with a script in `/etc/profile.d/`? – frennky Feb 19 '22 at 19:07

2 Answers2

6

Inside the application directory of the runner, there is a .env file, where you can put all variables for jobs running on this runner instance.

For example

LANG=en_US.UTF-8
TEST_VAR=Test!

Every time .env changes, restart the runner (assuming running as service)

sudo ./svc.sh stop
sudo ./svc.sh start

Test by printing the variable

enter image description here

Ran QUAN
  • 3,515
  • 1
  • 12
  • 9
  • This is a useful solution as well. I had run across the .env file in the docs at https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners#using-a-env-file-to-set-the-proxy-configuration but didn't know it could be used for variables beyond the proxy. – gsf Jun 12 '23 at 15:20
2

If you want to set a variable only for one run, you can add an export command when you configure the self-hosted runner on the Github repository, before running the ./run.sh command:

Example (linux) with a TEST variable:

# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/owner/repo --token ABCDEFG123456
# Add new variable
$ export TEST="MY_VALUE"
# Last step, run it!
$ ./run.sh

That way, you will be able to access the variable by using $TEST, and it will also appear when running env:

  job:
    runs-on: self-hosted
    steps:
      - run: env
      - run: echo $VAR

enter image description here


If you want to set a variable permanently, you can add a file to the etc/profile.d/<filename>.sh, as suggested by @frennky above, but you will also have to update the shell for it be aware of the new env variables, each time, before running the ./run.sh command:

Example (linux) with a HTTP_PROXY variable:

# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/owner/repo --token ABCDEFG123456
# Create new profile http_proxy.sh file
$ sudo touch /etc/profile.d/http_proxy.sh
# Update the http_proxy.sh file
$ sudo vi /etc/profile.d/http_proxy.sh
# Add manually new line in the http_proxy.sh file
$ export HTTP_PROXY=http://my.proxy:8080
# Save the changes (:wq)
# Update the shell
$ bash
# Last step, run it!
$ ./run.sh

That way, you will also be able to access the variable by using $HTTP_PROXY, and it will also appear when running env, the same way as above.

  job:
    runs-on: self-hosted
    steps:
      - run: env
      - run: echo $HTTP_PROXY
      - run: |
          cd $HOME
          pwd
          cd ../..
          cat etc/profile.d/http_proxy.sh

The etc/profile.d/<filename>.sh will persist, but remember that you will have to update the shell each time you want to start the runner, before executing ./run.sh command. At least that is how it worked with the EC2 instance I used for this test.

enter image description here

Reference

GuiFalourd
  • 15,523
  • 8
  • 44
  • 71