Bug: sccache fails with 'Permission denied' when using FSx volume clones as workspaces in Jenkins

[jorisdon]

Expected Behaviour

sccache should not fail when using FSx volume clones as workspaces in Jenkins.

Current Behaviour

"Permission denied" (EACCES) errors occur when building software residing in an FSx volume clone. The reason is that the sccache deamon runs as root and doesn't have write access to the directories where the source code is located, as the writeable flag is not set for 'others' and the files and directories are owned by ubuntu:ubuntu / ec2-user:ec2-user.

Possible Solution

There's a few potential resolutions for this issue:

1. Run the sccache service as the same user/group as the Jenkins build agent, by adding the following to the [Service] block in sccache.service;
   ubuntu build agents:

User=ubuntu
Group=ubuntu

Amazon Linux build agents:

User=ec2-user
Group=ec2-user

2. Run the sccache service as its own sccache system user. Introduce a new user (jenkins) on all builder nodes and run jenkins agents as that user instead of ubuntu/ec2-user as done currently. Introduce a new group (builder?) and add the sccache and jenkins users to that group.

Steps to Reproduce

1. Rewrite the Godot Jenkins build pipeline sample to use FSx volume clones to build from
2. Initiate a build job for the pipeline
3. Build will fail with errors like error: unable to open output file 'platform/linuxbsd/xkbcommon-so_wrap.linuxbsd.template_release.x86_64.llvm.o': 'Permission denied'

You can run sudo strace -f -p <sccache PID> -y -yy -Y -o ~/strace.log to get detailed information about the system calls invoked by the sccache daemon.

Cloud Game Development Toolkit version

latest