-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HOME is overridden for containers #863
Comments
If I may suggest a possible solution:
|
As we are also having trouble with this issue in our Build Actions, we used this workaround:
See: mkdir -p /github
ln -s /root $HOME # Create Symlink /github/home |
I created a bit similar issue about issues caused by setting |
@hoxu you touched on the most important bit:
|
Overriding |
Hola gracias salientes desde Los Mochis Sinaloa México. Soy mexicano y de familia numerosa saludos again asta luego.bestamosven línea. |
Also, at build the |
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 Add a first step to the job like - shell: bash
run: 'echo HOME=/home/sf | sudo tee -a $GITHUB_ENV' FWIW the Following steps will start with the expected HOME, as well as source resource files correctly, like |
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:
Let's start from the bottom, with 4. Regarding 3 - there's a specific 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 Summary:
** 🚨 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.** |
ping @TingluoHuang |
after some googling, I found https://stackoverflow.com/a/56685281/465684
As the comment says, there's no citation, no documentation around that, AND it also doesn't hold in reality. I ran a test here https://github.com/ysoftwareab/yplatform-test/actions/runs/1783086868 . test3 jobs depends on test1 and test2, and test3 doesn't have access to the test1 and test2 files, neither in the real $HOME, neither in /github/home, neither in $GITHUB_WORKSPACE. Afaik, one uses upload-artifacts and download-artifacts actions for sharing files between jobs. Just wanted to be exhaustive. |
Looking at the runner's sourcecode, there's another mention of this mount https://github.com/actions/runner/blame/9a829995e02d2db64efb939dc2f283002595d4d9/src/Runner.Worker/Handlers/ContainerActionHandler.cs#L174 I ran out of time so I cannot test this to be sure, but I guess the whole idea of overriding $HOME is to share state with a "docker container action" https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action 😞 |
Hi @andreineculau, I will mark this as an enhancement since this is working as expected, but obviously, this change could add some value. I am putting it in the enhancement backlog so it is considered in the future enhancements 😊 |
@nikola-jokic why do you say it is working as expected? Where is it documented that "variables CANNOT be overridden" is normal behaviour? As far as I, and others on this thread, can see - this is a BUG . A step can set new, but cannot override previous variables. That's some peculiar "expectation". EDIT: ignore this comment, I thought I'm replying in the #789 thread |
Hi @andreineculau, We are experiencing similar problems with the Issue 434, which is related to how we mount the fs to have those files re-used. After the discussion with the team, we marked it as a feature that we should work on in the near future. That problem is also very important to us. This issue is related to the HOME environment, which is used to share the state between the host system where the runner is executing, and the containerized application. Since issue 434 is considered a feature, I don't see why this issue would not fall under the same umbrella and should be picked up together. |
@nikola-jokic Apologies. My comment above was wrong, because I thought we were talking about #789 (not an excuse but I have a cold and I wasn't thinking right). I will read up on #434 and come back if needed. Thanks and once again sorry for the noise. |
@andreineculau, no problem 😊. I misunderstood the issue 789, so I re-opened it once I got it. There is a third party PR now related to that issue so it should be fixed as soon as it is merged. |
Im running a script on the CI in order to set new environment variables (such as JAVA_HOME) but its seems like it doesn't work
is that part of this issue? or is there a way to set env variable by a bash script? Note: seems like the container is not overridden the variable if it was set as |
Because GHA changes $HOME: actions/runner#863
work around actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
This is for actions/runner#863 which is causing "Preventing creation of Stack root '/github/home/.stack/'. Parent directory '/github/home/' is owned by someone else."
Can this be fixed in 2024, this should not be any feature or something, this is just totally non-sense and is a bug! |
After reading this whole thread, I'm really disappointed that this got re-labeled as an enhancement. This behavior is not only unintuitive and pointlessly disruptive to most non-trivial docker images, it's also something that thousands of Github Action users will run into and be completely confused by. That's real suffering. |
We are hitting the 1 hour time limit of Circle CI (Issue open-quantum-safe#166). This migrates the existing CircleCI job completely to Github Actions which has a 5 hour time limit. For the most part, this is pretty much a one-to-one migration. Since upstream OpenSSH provided its own set of Github Actions, I simply moved those to the `upstream-github` directory to avoid conflicts and preserve the source. I did run into two issues with getting the integration tests to pass. Beyond that, I ran into two issues that arose from migrating to Github Actions which need to be partched around. The combination of Github Actions' host with the OQS CI container results in a lazier reaping of zombie processes which breaks this test. In this test, ssh-agent is run as a subprocess to some arbitrary user command. This enables exclusive access to ssh-agent to that specific process. The way this works under the hood is that ssh-agent forks into a child process and the parent process exec's into the arbitrary command ([code ref](https://github.com/open-quantum-safe/openssh/blob/OQS-v9/ssh-agent.c#L2384)) which runs to completion. The child process than polls its parent process until it detects its own orphaned status and terminates itself. This, by design, results in a zombie process which must be reaped. The test's assertion uses `kill -0` to check for liveness, but that counts zombies as "alive". The workaround for this then is to add an additional check to assert that zombies are in fact "dead". The `percent` test tests % expansions inside SSH config files (e.g. home directory, username, port number). The assertion for the home directory uses the `HOME` environmental variable. Unfortunately, when running a container on a Github Runner, they unconditionally override the value of `HOME` with `/github/home` ([issue ref](actions/runner#863)) and this breaks the test assertion. The fix here is to get a more reliable reference for the home directory and use that for the assertion. Signed-off-by: gcr <gcr@amazon.com>
We are hitting the 1 hour time limit of Circle CI (Issue open-quantum-safe#166). This migrates the existing CircleCI job completely to Github Actions which has a 5 hour time limit. For the most part, this is pretty much a one-to-one migration. Since upstream OpenSSH provided its own set of Github Actions, I simply moved those to the `upstream-github` directory to avoid conflicts and preserve the source. I did run into two issues with getting the integration tests to pass. Beyond that, I ran into two issues that arose from migrating to Github Actions which need to be partched around. agent-subprocess zombie process reaping The combination of Github Actions' host with the OQS CI container results in a lazier reaping of zombie processes which breaks this test. In this test, ssh-agent is run as a subprocess to some arbitrary user command. This enables exclusive access to ssh-agent to that specific process. The way this works under the hood is that ssh-agent forks into a child process and the parent process exec's into the arbitrary command ([code ref](https://github.com/open-quantum-safe/openssh/blob/OQS-v9/ssh-agent.c#L2384)) which runs to completion. The child process than polls its parent process until it detects its own orphaned status and terminates itself. This, by design, results in a zombie process which must be reaped. The test's assertion uses `kill -0` to check for liveness, but that counts zombies as "alive". The workaround for this then is to add an additional check to assert that zombies are in fact "dead". percent expansion is broken due to Github's HOME override The `percent` test tests % expansions inside SSH config files (e.g. home directory, username, port number). The assertion for the home directory uses the `HOME` environmental variable. Unfortunately, when running a container on a Github Runner, they unconditionally override the value of `HOME` with `/github/home` ([issue ref](actions/runner#863)) and this breaks the test assertion. The fix here is to get a more reliable reference for the home directory and use that for the assertion. Signed-off-by: gcr <gcr@amazon.com>
We are hitting the 1 hour time limit of Circle CI (Issue open-quantum-safe#166). This migrates the existing CircleCI job completely to Github Actions which has a 5 hour time limit. For the most part, this is pretty much a one-to-one migration. Since upstream OpenSSH provided its own set of Github Actions, I simply moved those to the `upstream-github` directory to avoid conflicts and preserve the source. I did run into two issues with getting the integration tests to pass. Beyond that, I ran into two issues that arose from migrating to Github Actions which need to be partched around. agent-subprocess zombie process reaping The combination of Github Actions' host with the OQS CI container results in a lazier reaping of zombie processes which breaks this test. In this test, ssh-agent is run as a subprocess to some arbitrary user command. This enables exclusive access to ssh-agent to that specific process. The way this works under the hood is that ssh-agent forks into a child process and the parent process exec's into the arbitrary command ([code ref](https://github.com/open-quantum-safe/openssh/blob/OQS-v9/ssh-agent.c#L2384)) which runs to completion. The child process than polls its parent process until it detects its own orphaned status and terminates itself. This, by design, results in a zombie process which must be reaped. The test's assertion uses `kill -0` to check for liveness, but that counts zombies as "alive". The workaround for this then is to add an additional check to assert that zombies are in fact "dead". percent expansion is broken due to Github's HOME override The `percent` test tests % expansions inside SSH config files (e.g. home directory, username, port number). The assertion for the home directory uses the `HOME` environmental variable. Unfortunately, when running a container on a Github Runner, they unconditionally override the value of `HOME` with `/github/home` ([issue ref](actions/runner#863)) and this breaks the test assertion. The fix here is to get a more reliable reference for the home directory and use that for the assertion. Signed-off-by: Gerardo Ravago <gcr@amazon.com>
Here's a concrete example of problems caused by the 'unexpected' value of Code like this doesn't do what you would expect:
You'd expect this will avoid 'unknown host key' for ssh to the host in question. Sadly it doesn't and the reason appears to be that |
@kdvolder Exactly my experience. Anywhere where tilde is used you need to "expand" it manually to be the "real" home, not the hijacked one. My Dockerfile is full of things like:
This is a sub-optimal “solution” at best. In some cases the tool internally uses tilde and there is no way to “re-hijack” is back to the “real” HOME. |
I've added this as a very first step for each of my jobs in the workflow: steps:
- name: Preserve $HOME set in the container
run: echo HOME=/root >> "$GITHUB_ENV"
This has to be the very first step in the job and it should not be a symlink as suggested above or the contents of your |
Describe the bug
If passing the
HOME
environment variable to a container configuration,it will get ignored and set to
/github/home
anyway as perrunner/src/Runner.Worker/ContainerOperationProvider.cs
Line 258 in 4e85b8f
To Reproduce
A workflow with
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
The text was updated successfully, but these errors were encountered: