Running docker currently mounts the docker.sock file into the container.
This was introduced in 2ab738c083 but
there is no explanation provided.
The docker.sock file is only needed if we want to run docker inside the container
to create other images or start other containers.
I searched through the code and I did not find any such use.
In particular, on fedora this gives permission denied because docker.sock
is owned by root and the container runs under an unprivileged user.
One has to change the permissions of docker.sock
(which is actually a link to /run/podman/podman.sock) to be writeable by the user.
If we don't need to use docker inside the containers, then we can remove this file,
thus we can run this GitHub action as an unprivileged user out of the box.
In self hosted runners in fedora with SELinux enabled,
it sometimes gives a random error
```
Error: lsetxattr /var/run/docker.sock: operation not permitted
Error: The process '/usr/bin/docker' failed with exit code 126
```
This seems to happen with docker.sock which is a link to
/run/podman/podman.sock
looks like lsetxattr is broken for links.
* feat: compatibility with self-hosted runners with SELinux
When using a self-hosted runner with SELinux (fedora)
volumes need to be mounted with ":z" in order to have write access
these flags are documented [here](https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label)
* Ensure folders are created
* use if instead of short circuit
* ts convention either inline or use braces
* Fix linting
* fix linting errors
Co-authored-by: Webber Takken <webber.nl@gmail.com>
* Run yarn upgrade in order to resolve security vulnerability
* Remove unneeded git add from pre-commit hook
* Update packages
* Update non-eslint packages
if there is both a unity package and a test-project in one github repo, then the token generation process is created Library folder and then the build of the test project breaks. Requires a tilde to ignore Library folder in _activate-license.
Or need set the path ACTIVATE_LICENSE_PATH from the global ENV in runtime-action
Co-authored-by: Maxim Vorobyev <dolphinikk@gmail.com>
Paul Pacheco
dependabot[bot]
Frostebite
David Finol
Webber Takken