We start to use rust for backend development. To speed up compilation in our bitbucket pipelines, we want to use sccache (https://github.com/mozilla/sccache).
Locally, sccache works perfectly fine. Inside the bitbucket pipeline, sccache failes hard with a "Connection refused (os error 111)" (please see more under https://github.com/mozilla/sccache/issues/1745).
Is there anything known about a similar problem in bitbucket pipelines? This is really a pain point for us.
Looks like there is an issue with opening your config file. The usual suspects are does the file actually exists at the time you call the parse command and does it have the correct permissions.
Also, do note that files and folders do not pass by default from one step to another, so if you didn't cache the config file/folder explicitly, it won't be available in the next steps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your answer. Unfortunately sccache works without config file. I have no config file locally, too.
So this might be not the issue. For me it looks like something with the internal network is broken in the pipeline step. The client cannot connect to the server on localhost port 4226.
Are there any restrictions in this direction? Is there anything how I can test the internal network in a bitbucket pipeline step?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @michael.seele ,
I'm not really familiar with sccache, but I've tried to setup a simple pipeline to start the scchace server and check if it was listening on port 4226 using the following YML file :
image: rust:latest
pipelines:
default:
- step:
script:
- export SCCACHE_LOG=trace
- cargo install sccache
- sccache --start-server
- sleep 15
- sccache --show-stats
- apt-get update
- apt-get install net-tools
- netstat -tulpn
The log output of the above pipeline indicates that the server was started, and the client was able to connect successfully when the command sccache --show-stats was executed. The last netstat command was to confirm that sccache server was still listening for requests on port 4226.
With that in mind, I see the difference in your configuration is that you are using the AWS s3-stored cache. In order to find out if some s3 setting is the culprit here, could you please try using the sccache option of local cache instead and see if you get the same error?
Thank you, @michael.seele !
Patrik S
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Patrik S thanks for contacting me and the great reply.
It seems to be an s3 connection problem. By using a local cache, the pipeline is successful. That solves the pipeline problem and I need to look at the s3 permissions.
By the way, a better error message from sccache would have saved us hours. I will report this back to sccache.
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.