Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: "pip" cache having nothing installed leads to post-run error #815

Open
2 of 5 tasks
jamesbraza opened this issue Feb 7, 2024 · 4 comments
Open
2 of 5 tasks
Labels
feature request New feature or request to improve the current logic

Comments

@jamesbraza
Copy link

jamesbraza commented Feb 7, 2024

Description:

I have this:

        runs-on: 'ubuntu-latest'
        steps:
            -   uses: actions/setup-python@v5
                with:
                    python-version: '3.10'
                    cache: 'pip'

Bumping python-version from '3.10' to '3.12', I am now getting this error during Post Run actions/setup-python@5:

Post job cleanup.
Error: Cache folder path is retrieved for pip but doesn't exist on disk: /home/runner/.cache/pip

Action version:

v5

Platform:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

Tools version:

3.10.13 to 3.12.1

Expected behavior:

I expect setup-python to somehow not error itself.

Seemingly related issues:

Actual behavior:

Here is the output of Run actions/setup-python@v5

  with:
    python-version: 3.12
    cache: pip
    check-latest: false
    token: ***
    update-environment: true
    allow-prereleases: false
  env:
    ...
Installed versions
  Successfully set up CPython (3.12.1)
/opt/hostedtoolcache/Python/3.12.1/x64/bin/pip cache dir
/home/runner/.cache/pip
pip cache is not found

Here is the output of Post Run actions/setup-python@5:

Post job cleanup.
Error: Cache folder path is retrieved for pip but doesn't exist on disk: /home/runner/.cache/pip
@jamesbraza jamesbraza added bug Something isn't working needs triage labels Feb 7, 2024
@jamesbraza
Copy link
Author

Okay, I figured it out, the issue was not pip installing anything! 😆

pip installing some placeholder package like isort solves the problem, the error goes away.

Thus the conclusion is, if "pip" cache is specified, then post run caching should either:

  • Be robust against no packages being installed into pip cache
  • Throw a better error (e.g. "Cache folder path is retrieved for pip but doesn't exist on disk, did you actually pip install anything?")

@jamesbraza jamesbraza changed the title Python 3.10 to 3.12: getting 'Error: Cache folder path is retrieved for pip but doesn't exist on disk' Bug: "pip" cache having nothing installed leads to post-run error Feb 7, 2024
@HarithaVattikuti
Copy link
Contributor

Hello @jamesbraza
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

@priyagupta108
Copy link
Contributor

Hi @jamesbraza 👋 , Thank you for sharing your experience and suggestions!
Your insights into enhancements for post-run caching are valuable. We’ll work on it when we get the chance.
For now I'm going to close the issue. If you have any concerns please feel free to ping us.
We appreciate your understanding and cooperation :)

@jamesbraza
Copy link
Author

jamesbraza commented Feb 21, 2024

Usually an issue stays open until it's resolved, not closed as completed when it wasn't.

Think of issues as targets to aim for, but closing them defeats that

@aparnajyothi-y aparnajyothi-y added feature request New feature or request to improve the current logic and removed bug Something isn't working labels Feb 22, 2024
bloodearnest added a commit to opensafely-core/job-runner that referenced this issue Sep 30, 2024
This was prompted by a bug in setup-python@v5, which means that the
post-clean-up job will fail if you do not actually install anything in
pip, as the cache directory will not be created. This has hit a few of
our GHA workflows.

actions/setup-python#815

The reason this was triggering for job-runner was that the current CI
setup was pretty much broken.

Firstly, the PYTHON_VERSION env var was not being set, which meant that
every test run was always testing 3.8, not 3.9 or 3.10 as per the
matrix.  Fixing this meant a bit of windows/powershell finesse.  It
always explains the fact that for some reason, even though we have 22.04
in the matrix, we did not run the tests on it (this was what triggered
the above failure).

Additionally, we were going to the trouble of installing/starting docker
on macos, and then not even running the docker tests. This feels like we
had the abandonded attempts of getting docker tests running on macos.

To fix this, I just removed those steps and fully embraced not running
docker tests (which required excluding a few more tests).  Additionally,
macos-12 is old, and has very slow runners, so I took the opportunity to
update to using macos-13.

I did attempt to use our opensafely-core/setup-action, but it still
seems to have problems with just on windows, and my yak stack was full.
bloodearnest added a commit to opensafely-core/job-runner that referenced this issue Sep 30, 2024
This was prompted by a bug in setup-python@v5, which means that the
post-clean-up job will fail if you do not actually install anything in
pip, as the cache directory will not be created. This has hit a few of
our GHA workflows.

actions/setup-python#815

The reason this was triggering for job-runner was that the current CI
setup was pretty much broken.

Firstly, the PYTHON_VERSION env var was not being set, which meant that
every test run was always testing 3.8, not 3.9 or 3.10 as per the
matrix.  Fixing this meant a bit of windows/powershell finesse.  It
always explains the fact that for some reason, even though we have 22.04
in the matrix, we did not run the tests on it (this was what triggered
the above failure).

Additionally, we were going to the trouble of installing/starting docker
on macos, and then not even running the docker tests. This feels like we
had the abandonded attempts of getting docker tests running on macos.

To fix this, I just removed those steps and fully embraced not running
docker tests (which required excluding a few more tests).  Additionally,
macos-12 is old, and has very slow runners, so I took the opportunity to
update to using macos-13.

I did attempt to use our opensafely-core/setup-action, but it still
seems to have problems with just on windows, and my yak stack was full.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

4 participants