-
Notifications
You must be signed in to change notification settings - Fork 565
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
Cannot create directory ‘/opt/hostedtoolcache’ after recent release #459
Comments
Hi, @kenorb 👋 Thank you for that issue, we will investigate it and get back to you with updates. |
Hello @kenorb. Could you please take a look at this pull request. I think it can be related to your issue. |
@dmitry-shibanov yes, it would be directly related. RUNNER_TOOL_CACHE on GitHub hosted vs Self Hosted is different. Self Hosted
Hosted
This variable is a default, I'd expect whilst we might want to make sure it exists, replacing it with a fixed path might cause consumers of the action to experience unexpected behaviour. We're experience similar issues, as the runner is intentionally not running as root, so will not be able to write to that path. |
@techman83 Alternatively, you can choose the installation directory to any location by setting AGENT_TOOLSDIRECTORY env. variable, but it should not be used because of: |
@dsame yes, that is a work around. Why would an action choose to override this variable as opposed to being a consumer of it? If for instance there is another workflow step that uses this path before, and after the python actions setup, the behaviour would be unexpected.
I see what you are saying here, that it relates to actions/python-versions. However reading through the source code, it uses RUNNER_TOOL_CACHE environment variable if AGENT_TOOLSDIRECTORY is not provided. So, realistically there shouldn't be a requirement to override this variable. Rather when AGENT_TOOLSDIRECTORY is specified, use that path instead of RUNNER_TOOL_CACHE. Along with that, actions/python-versions is likely to be run before actions/setup-python, so even allowing write to |
@techman83 The reason why the python must be installed there described in the README
Unfortunatelly In the previous versions of But in some environments an user may have not ability to create Thank you for your question, feel free to ask more if you still have some problems - it really helps to improve the code. |
@dsame - Apologies if I came across as blunt yesterday, still getting over covid and had already shaved many yaks. Having read through Log
Files in the local docker container connected to my test org:
So to me it doesn't look necessary, and adds extra steps when configuring a self hosted runner, along with breaking existing workflows (though there is always that one guy). One of the benefits is normally that the runner is pretty self contained. |
And for completeness to check hosted (I haven't checked self hosted Mac/Windows, I have not convenient access to either). Linux Hosted:
Windows Hosted:
Mac Hosted:
|
As you already have noted, the python is installed in
This works in many cases, but the README warns: Installing python in the directory other then Does it make sense now? |
@dsame not really. I am aware of the warning, but this doesn't match the behaviour of the
Internally they use a
Part of the use case (not one we utilise) is for runners without internet access. You can see references to the documentation for this path. Other use cases maybe mounting a shared volume for all your runners, so they can access the same tool cache.
Overriding this path within an action is unexpected and doesn't match GitHub's documented use of that variable. To be explicit, that documentation specifically calls out
|
This aligns the tool cache path logic with the process used by actions/python-versions, maintaining the ability to locate the version binaries, and fixing self-hosted runners. Fixes actions#459
This updates and simplies the tool cache documentation to match the implementation in both and Relates actions#459
@dsame I'm curious, what environment variables would we have to set to revert back to the previous behavior? |
@k24dizzle Namely for Pytjon-3.11.0-betat.4 as in the log above:
|
@k24dizzle - Alternatively, you can use the context variable.
|
@techman83 do you think it is correct to say the problem is two pieces of the documentation points to the different locations? |
@dsame I don't, I hope I have articulated clearly enough to show that this is a regression for self hosted users. Even though that regression technically aligns the behaviour of |
Hi, I am working on the same repo as @kenorb where we are using the setup-python GH action. I ended up following the suggestion from @techman83: env:
AGENT_TOOLSDIRECTORY: ${{ runner.tool_cache }}
uses: actions/setup-python@v4
with:
python-version: "3.11.0-beta.4" This really makes me wonder why Cf this comment from @techman83 :
That would make a lot more sense to me and by doing so we wouldn't have to tinker with |
Because for the robust shared library loading python must be installed in |
Fair enough, I guess I am probably looking at this trough the |
|
@dsame I appreciate what it is trying to do, but those issues relate to I don't think it's correct to alter |
@dsame - hopefully this demonstrates things a bit better -> https://github.com/Effortless-Networking/test-setup-python/runs/7384473653 In fact, I was able to omit all those lines entirely. And everything "just worked". |
A change was made to fix a long standing set of issues, relating to the tool path that actions/python-versions historically used. However this was fixed in actions/python-versions@5815b5c and is no longer required. Fixes actions#459
This updates and simplies the tool cache documentation to match the implementation in both and Relates actions#459
I did however find a case where this fixed something by accident. When setting Environment variables are at least contextual, so it wouldn't be the worst outcome. Demonstration -> https://github.com/Effortless-Networking/test-setup-python/runs/7385216270 Edit: I realise this is the case in 162 however whilst 401 is also a self hosted runner, it shows things are broken out of the box and don't need to be. |
@dsame python is relocable as it is built relocable as of rpath support in LDFLAGS (https://github.com/actions/python-versions/blob/main/builders/ubuntu-python-builder.psm1#L34), harcdoding the toolcache directory introduces UB against how we build python. ldd/strace output from the github-hosted runner: and the same output from the self-hosted one |
This aligns the tool cache path logic with the process used by actions/python-versions, maintaining the ability to locate the version binaries, and fixing self-hosted runners. Fixes actions#459
This updates and simplies the tool cache documentation to match the implementation in both and Relates actions#459
with handling AGENT_TOOLSDIRECTORY for both hosted + self-hosted. Fixes actions#459
This updates and simplies the tool cache documentation to match the implementation in both and Relates actions#459
with handling AGENT_TOOLSDIRECTORY for both hosted + self-hosted. Fixes actions#459
This updates and simplies the tool cache documentation to match the implementation in both and Relates actions#459
This fixes the tool cache path for self-hosted runners, along with handling AGENT_TOOLSDIRECTORY for both hosted + self-hosted. Fixes actions#459
This updates and simplies the tool cache documentation to match the implementation in both and Relates actions#459
This fixes the tool cache path for self-hosted runners, along with handling AGENT_TOOLSDIRECTORY for both hosted + self-hosted. Fixes actions#459
Shared libraries for the Mac python builds are not configured with the relocatable flag, thus must always be configured with the hosted path. Relates actions#459
Shared libraries for the Mac python builds are not configured with the relocatable flag, thus must always be configured with the hosted path. Relates actions#459
This updates and simplies the tool cache documentation to match the implementation in both and Relates actions#459
Shared libraries for the Mac python builds are not configured with the relocatable flag, thus must always be configured with the hosted path. Relates actions#459
We where having this issue while setting up our own runners with the ubuntu example in: https://github.com/philips-labs/terraform-aws-github-runner. |
Description:
The following error start happening after the recent action release:
Action version:
v4
Platform:
Runner type:
Tools version:
Repro steps:
Expected behavior:
Won't error.
Actual behavior:
It errors.
The text was updated successfully, but these errors were encountered: