You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Add a note to the fixture in test_util.py that its ability to
create files where rmtree will fail is contingent on not running
as root (since root doesn't need to own a dir to delete from it).
- Create a non-root user in the container. Give it the same UID as
owns the repository files that are shared with the container.
Also create a group with the GID of the repository files that
are shared with the container and add the user to the group,
though that is less important. Actually creating the user ensures
it has a home directory and may help some commands work. Passing
`options: --user 1001` under `container:` will not work because,
even if we didn't make the user, the `apk add` commands still
need to run as root.
- Run all commands as the new non-root user, except for the system
administration commands that install needed apk packages and set
up the new non-root user account. To continue clearly expressing
each step separately and have them automatically run in the
container, this uses the hacky approach of having the default
shell be a "sudo" command that runs the script step with "sh"
(and passes the desired shell arguments).
- Preserve environment variables that may have been set by or for
the GHA runner, in commands that run as the non-root user. That
is, pass those through, while still removing/resetting others.
If this is not done, then the variables such as `CI`, which the
init-tests-after-clone.sh uses to proceed without interactive
confirmation, will not be set, and that step will fail. However,
I think it is also a good idea to do this, which is why I've
included all the relevant variables and not just `CI`.
- Now that a non-root user is using "pip", stop using a venv, at
least for now. The other test jobs don't use one, since the
runners are isolated, and a container on a runner is even more
isolated. But it may be best to bring the venv back, maybe even
on the other test jobs, or alternatively to use "python -m pip"
instead of "pip", to ensure expected version of pip is used.
- Don't add safe.directory inside the container, in the hope that
this may not be necessary because the cloned repository files
should have the same UID (and even GID) as the user using them.
But I expect this may need to be put back; it seems to be needed
separately from that, as actions/checkout automatically attempts
it for the git command it finds and attempts to use.
This is not the only approach that could work. Another approach is
to make use of the container explicit in each step, rather than
using the `container` key. I think that would make the relationship
between the commands here and in other test workflows less apparent
and make the workflow a bit less clear, but it could also simplify
things. A third approach is to create an image with the needed apk
packages and user account, which switches to that user, by writing
a Dockerfile and building in image, producing it in a previous
job and sharing the image with the job that runs the tests so that
`container` can still be used. That might be ideal if it could be
done with upload-artifact and download-artifact, but I think
`container` only supports getting images from registries.
0 commit comments