brandonlwhite / pipx-install-action Goto Github PK

Restoring the pipx cached venv is resulting in errors like:

/usr/bin/tar: ../../../../../opt/pipx/shared/include: Cannot utime: Operation not permitted
/usr/bin/tar: ../../../../../opt/pipx/shared/include: Cannot change mode to rwxr-xr-x: Operation not permitted
/usr/bin/tar: ../../../../../opt/pipx/shared/bin: Cannot utime: Operation not permitted
/usr/bin/tar: ../../../../../opt/pipx/shared/bin: Cannot change mode to rwxr-xr-x: Operation not permitted

https://github.com/BrandonLWhite/pipx-install-action/actions/runs/7464191929/job/20310605551#step:4:20

This looks like a filesystem permission issue. How is pipx able to install venvs to these locations, but not the cache restore?

Actually, I'm noticing that only the shared restore is failing. I think this is because in the Github provided runners, pipx has already had some packages installed like ansible and yamllint which you can catch a glimpse of in the pipx list --json output. When developing this action locally, I used ACT which doesn't pre-install anything, so this is different than how it behaves in GHA.

I think the best solution is to remove the shared caching and assume it will already be there to to preinstalled packages, along with updating the test ACT workflow to pipx install a package first before calling pipx-install-action. Or, I could add a condition that checks if the PIPX_SHARED_LIBS already exists. before invoking the cache restore.

Pipx uses the system Python to install the CLI tools. This can be different if a GHA workflow has used setup-python to install a different version.

In order to fix this:

1. Invoke pipx environment --value PIPX_DEFAULT_PYTHON to get the path the python that pipx uses.
2. Invoke the result in place of the hardcoded python to get the version string for hashing keys.