Test in Docker with Alpine Linux on CI by EliahKagan · Pull Request #1826 · gitpython-developers/GitPython

@EliahKagan

- 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.