Open ZelboK opened 1 year ago
Thanks @ZelboK. I had thought this fallback to the local filesystem would already be working, but I think you're the first external person to try it, so we haven't tested this yet ;)
@trxcllnt and @cwharris will look into it and we'll try to get it fixed asap.
@ZelboK in the meantime, an easier way for you to work around the problem is to run these commands inside the container:
unset SCCACHE_BUCKET
unset SCCACHE_REGION
sccache --stop-server
sccache --start-server
Basically, unset those envvars and then restart the sccache server. This will automatically switch to using your local file system for the cache.
Hey @ZelboK, the devcontainer startup scripts should be automatically detecting that you don't have read/write access to the bucket and automatically adjusting sccache configuration. We have tests for some of these scenarios, so it's difficult to say what's causing your problem specifically.
Can you give us step-by-step instructions on how to reproduce the situation?
Are you authenticating with github (even though your user won't provide s3 access)?
Are the startup scripts completing successfully?
What are the values of SCCACHE_BUCKET
, SCCACHE_REGION
, and SCCACHE_S3_NO_CREDENTIALS
after the startup scripts have finished running?
Hi,
I've never actually used devcontainers before contributing, so I apologize for any misunderstandings on my end. However I do recall at some point authenticating with Github, I didn't think much of it because I just wanted to get started. From what you've described it sounds like that could be the culprit.
I will get back to this issue later today when I finish work with more details. I figured the github authentication part was worth mentioning right now though.
@cwharris I have the same issue Repro steps:
echo "$SCCACHE_BUCKET $SCCACHE_REGION $SCCACHE_S3_NO_CREDENTIALS"
rapids-sccache-devs us-east-2Thanks @bendyna! That's really helpful. We'll look into this ASAP.
We've pushed a release that contains a fix to at least one of the sccache env variable issues. Can you retry and let us know if the issue is resolved for you?
We've pushed a release that contains a fix to at least one of the sccache env variable issues. Can you retry and let us know if the issue is resolved for you?
It works for me now! cuda 12.3 gcc 12 is what i tried.
Is this a duplicate?
Type of Bug
Compile-time Error
Component
Not sure
Describe the bug
The devcontainers currently rely on
sccache
. For people who are not employees of NVIDIA you will not be able to rely on the cloud so obviously sccache should default to the home directory. However with the build scripts, what happens is thatsccache
will try to remotely connect to the server, fail, and then stop compiling.Here's a modification to the
devcontainer.json
I did that fixes the problem, but this isn't a permanent solution and is more something I did on my end because I just wanted to get set up right away.As you can see I am removing the cloud from the picture and just configuring it to my local.
How to Reproduce
Expected behavior
And when you run with
SCCACHE_LOG=debug SCCACHE_NO_DAEMON=1
the following output appears:Reproduction link
No response
Operating System
all dev containers
nvidia-smi output
No response
NVCC version
No response