-
Notifications
You must be signed in to change notification settings - Fork 553
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
Four days ago, Python installed to /opt/hostedtoolcache, but today it installed to .../_work/_tool. #485
Comments
Hi @dcharles-godaddy, thank you for your report, we will take a look at this. |
I ran into this as well. I don't have a workaround yet though. |
Was able to apply a workaround by adding an environmental variable, as TS mentioned:
|
Yes, setting |
It looks like https://github.com/actions/setup-python/pull/466/files#diff-8164d45a0a98040cbf5161c5b6e696920163460bea5f24100a7a01720c4a9a91 might be responsible for this behavioral change. |
Actually, I take this back. That change seems tangentially-related, but in my company's environment we're seeing this problem occur only on our self-hosted runner and not on GitHub hosted runners (we are invoking @dcharles-godaddy are you seeing this on a self-hosted runner or a GitHub hosted runner? |
I encountered this as well, although the self-hosted runner I'm using has not used Since I did not want to change the runner's configuration, I worked around the problem by setting the - name: build dependencies
env:
CFLAGS: "-I/path/to/runner/_work/_tool/Python/3.10.1/x64/include/python3.10"
run: ... This let my build find However, nothing has changed recently with the runner, the workflow, or the Python version I'm using, so I'd love to understand why it's now getting the include path wrong. |
@ottumm , I'm seeing it on a self-hosted runner:
It's actually the same version of the runner producing both the success and the failure. |
We're also seeing the same issue. Unfortunately we don't have permissions to create the |
The include hack did work for us to move forward. |
@vsafonkin - we hit this issue yesterday as long as quite a few other python teams in our company. The commonality seems to be running on ubuntu on a self-hosted GHA runner. The CFLAGS workaround mentioned above is helping teams to move forward on this. Is there any more information we can provide to diagnose / resolve as this is affecting a lot of teams and GHA workflows. I haven't been able to track this down to any changes in |
Hi @eware-godaddy, you can use any custom directory to install python on your self-hosted runner using https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#linux |
I'm going to close this issue. Please, feel free to reopen it if you have any concerns. |
Description:
Four days ago, Python installed to
/opt/hostedtoolcache
, but today it installed to.../_work/_tool
. This manifested as a failure to findPython.h
while building the native dependencies ofpython-ldap
. Somehow, the installation procedure ofpython-ldap
knew to put-I/opt/hostedtoolcache/Python/3.8.10/x64/include/python3.8
on the command line, but there was nothing in the/opt/hostedtoolcache
folder. I'm currently working around this by setting theAGENT_TOOLSDIRECTORY
environment variable to/opt/hostedtoolcache
in my workflow.Action version:
b55428b
Platform:
Runner type:
Tools version:
3.8.10
Repro steps:
Expected behavior:
I would expect this to install Python to
/opt/hostedtoolcache
like it previously did.Actual behavior:
It now installs Python to
.../_work/_tool
within the job's workspace.The text was updated successfully, but these errors were encountered: