actions / actions/actions-runner-controller

How to Customize Runner Environment?

Open
#1,135 25 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Go
Stars
6.5k
Forks
1.5k
Avg merge
2d 2h
Merged PRs (30d)
27

Description

We are extending the runner base image to provision additional software similar to what GitHub does in their virtual environments. These provisioners also need to set up additional environment variables dynamically since they install software with dynamic versions. The natural choice to do so is by adding those environment variables to /etc/environment. However, this file is never loaded by the runners.

Hence, we set out to find out what is going on, and it seems that there is no reliable way to actually do this, other than manipulating files of the base image. This is obviously brittle, since those files can change at any time and are not standardized like the files of the operating system (e.g. /etc/environment). Let me explain what we found.

The entrypoint is set to /usr/local/bin/dumb-init and the initial command is set to /entrypoint.sh. The /entrypoint.sh script copies all non-dot files from /runnertmp to /runner.^cpr Later it replaces the standard runsvc.sh with a pachted runsvc.sh.^patched This file contains the following lines:

https://github.com/actions-runner-controller/actions-runner-controller/blob/0b9bef2c086a54b0731fa7aa0a6bd7cb856b48ee/runner/patched/runsvc.sh#L7-L13

The .path file can never exist (unless it would be created by some of the commands that are being called in /entrypoint.sh) since dot files are not copied over to /runner. The line that states that this is the place to customize the environment is for sure well intended, but assumes that editing alien scripts is done by a human, which is not the case for us. Customizing it with automation is – as stated before – a bad idea since it may break a lot of things at any point in time.

Imho it would be best to simply read /etc/environment since that is what it is intended for, but maybe there are good reasons not to do so?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with runner/entrypoint.sh, especially the /runnertmp copy and patched runsvc.sh replacement, then inspect runner/patched/runsvc.sh lines 7-13. Determine a supported way for dynamically provisioned environment variables to reach runner processes without editing generated scripts. Done means the customization path is reliable and the requested variables are available to the runner.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, kubernetes, shell
Domain
ci-cd, devops, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.