Closed thomas-moulard closed 3 years ago
Is this because the image is running as root?
Not sure, but I believe the workflow agent may run as root, but I set rosbuild
as the default user. Without this, the rosbuild
don't have write-access to the default directory and the action fails.
When I docker run -it <image_name> bash
this image, there's not even a home directory. Is the workflow doing something extra?
Home directory with correct permissions can be created by running mkhomedir_helper
as root.
Anyway, try useradd -m
in setup-ros.sh
?
After some digging, it turns out the home directory that rosbuild
(or any default user) uses is /github/home/
, the result of GitHub actions overriding the $HOME variable. /github/home/
is actually a mapped directory (from docker -v ...
), which means it starts off being owned by root
.
I wonder if we changed the create --user
option, then rosbuild
would have permissions to mounted volumes? Like:
container:
image: setup-ros-docker-blah
options: --user rosbuild
Not sure if this affects permissions, though
I got this error Error: EACCES: permission denied, open '/__w/_temp/_runner_file_commands/set_env_a8e7d409-8c7f-43c6-88b8-ba5086666ae6''
during aws-actions/configure-aws-credentials@v1.5.4
I tried to chown /__w/
as well but if I do that, with some reason another error then popped up Error: Access to the path '/home/runner/work/_temp/_github_workflow/event.json'
. Not sure why access to /home
is revoked after adding /__w/
to the chown list. I also tried to chown both /home/
and /__w/
but it also doesn't work.
I got this error
Error: EACCES: permission denied, open '/__w/_temp/_runner_file_commands
...
Yes - we are seeing this for all users of these images right now, I am looking into it
Description
To successfully using this image in an action, the workflow needs to call:
- run: sudo chown -R rosbuild:rosbuild "$HOME" .
Expected Behavior
This step should not be necessary.
Actual Behavior
Step is necessary.