HOME is overridden for containers

[andreineculau]

Describe the bug
If passing the HOME environment variable to a container configuration,
it will get ignored and set to /github/home anyway as per

runner/src/Runner.Worker/ContainerOperationProvider.cs

Line 258 in 4e85b8f

container.ContainerEnvironmentVariables["HOME"] = container.TranslateToContainerPath(tempHomeDirectory);

To Reproduce

A workflow with

jobs:
  main:
    runs-on: ubuntu-latest
    container:
      image: 'rokmoln/sf-ubuntu-bionic-common:0.2.80'
      options: '--user sf:sf' # this user's home is /home/sf
      env:
        HOME: /home/sf # tried to change HOME from /github/home to /home/sf. doesn't work
    steps:
      - shell: bash
        run: |
          echo $HOME

will echo /github/home instead of /home/sf.

Expected behavior
Expected HOME to be left as is, as sf user's HOME,
or at the very least to be allowed to enforce it via the env dictionary.

Runner Version and Platform

2.274.2

What's not working?

N/A

Job Log Output

N/A

Runner and Worker's Diagnostic Logs

N/A

[andreineculau]

If I may suggest a possible solution:

• set HOME only if not already set
• set GITHUB_HOME or GITHUB_RUNNER_HOME in order to allow devs not to hardcode /github/home in case there's a use-case to access the runner's home from inside a container.

[robin-rpr]

As we are also having trouble with this issue in our Build Actions, we used this workaround:

Note: We are expecting the /github/home folder to not exist yet in the container.

1. Create the /github directory
2. Create a Symlink with $HOME

See:

mkdir -p /github
ln -s /root $HOME # Create Symlink /github/home

[hoxu]

I created a bit similar issue about issues caused by setting HOME: #1146.

[andreineculau]

@hoxu you touched on the most important bit:

On a related note, it would be really nice if the GitHub runner's parameters to docker containers were documented clearly somewhere.

[JJ]

Overriding $HOME causes all kinds of trouble, to no obvious benefit...

[vamper424]

Hola gracias salientes desde Los Mochis Sinaloa México. Soy mexicano y de familia numerosa saludos again asta luego.bestamosven línea.

[Taknok]

Also, at build the HOME is defined by image/distribution to /root for example. Then when running, the HOME is overwritten by GitHub to /home/github. This is causing issues with some tools installed in image.

[andreineculau]

I can update this thread for future readers with my current workaround, that doesn't require messing with the filesystem as in #863 (comment) , but does require sudo, maybe tee.

Add a first step to the job like

- shell: bash
  run: 'echo HOME=/home/sf | sudo tee -a $GITHUB_ENV'

FWIW the sudo tee is needed because $GITHUB_ENV will be owned by another user. If you want to skip tee, you can run sudo sh -c "echo HOME=/home/sf >> $GITHUB_ENV"

Following steps will start with the expected HOME, as well as source resource files correctly, like ~.profile ~/.bash_profile etc

[andreineculau]

On another topic, driven by #863 (comment) "no obvious benefit", I have started thinking what can such a benefit be and I've come with these possible benefits:

1. persist state between container startups/shutdowns
2. persist state with host
3. persist state between containers
4. control the environment via .profile, .bash_profile, .curlrc, etc

Let's start from the bottom, with 4. /github/home is empty. So the only way to reason around that is if Github wants NO environment, in case they found cases where settings in resource files create unexpected behaviour. Sounds far fetched.

Regarding 3 - there's a specific volumes setting. "You can use volumes to share data between services or other steps in a job." Interesting formulation. First of all, did anyone see if Github overrides $HOME for services as well? I didn't. Secondly "other steps in a job" ?! I have just ran a test, and Github doesn't shuts down the container after each step. State is maintained between steps, and furthermore, action steps (i.e. steps with uses:some/action@ref) also run in the same container, having access to the same state.

Regarding 2. Which host? Either you run the job in a container or in a real/virtual machine.

Regarding 1. As mentioned for 3., state seems to be maintained. There's one particular case that I haven't tested, because I don't know where to look to understand how it works, how it should be invoked - docker hub action https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-a-docker-hub-action . Like ok, you reference an image hosted by hub.docker.com, what then? The docs reference an alpine image. How do you run shell commands? Or do they mean that you can package a docker image with a action.yml file in the WORKDIR, and they would run that. I really don't know how that works. But it could be that they start another container based on that image, set HOME to the same /github/home mount, same with GITHUB_WORKSPACE and maybe others, and thus share state though your job and the action step run isolated otherwise.

Summary:

• ❓ couldn't find a benefit
• 🙏 can someone enlighten me if a service also has $HOME mounted as /github/home ?
• 🙏 can someone enlighten me how a docker hub action step is intended to be used, how it works?

** 🚨 THE BEST thing would be if someone at Github can spend some minutes just to clarify WHY? I'm starting from the premise that there is a benefit. Something that evades some of us. If we understand why, then maybe we can even start using Github in different/better ways.**

[andreineculau]

ping @TingluoHuang