Crashlytics data directory at /?/.crashlytics could not be created

[mjsobremonte]

Occurs on both pipeline and freestyle jobs. Occurs on both Fabric Beta Publisher Plugin v2.0 and v1.8

Jenkins setup : Containerized Jenkins v2.161-alpine master node. Builds are executed remotely on a native ubuntu linux slave via ssh connector.

Possibly trivial but the only difference from other working instances is that this Jenkins master container runs as a specific user but has no problems with any other plugins or jobs except for this.

Executing command: [java, -jar, /tmp/crashlytics-devtools1568676034696283941.jar, -androidRes, ., -apiKey, xxx, -apiSecret, xxx, -androidManifest, /tmp/xml2451665321740410998.tmp, -uploadDist, /tmp/app-build-tmp7348470153513108592apk, -betaDistributionNotifications, false]
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Crashlytics data directory at /?/.crashlytics could not be created.
    at com.crashlytics.tools.android.DeveloperTools.<clinit>(DeveloperTools.java:114)
Temporary app-build-tmp7348470153513108592apk got deleted = true
Temporary xml2451665321740410998.tmp got deleted = true
Temporary crashlytics-devtools1568676034696283941.jar got deleted = true
Build step 'Upload .apk to Fabric Beta' marked build as failure

Occurs even with a very basic upload job :

[mjsobremonte]

Update : Seems running the master node as a docker container with an underprivileged host user is the cause of the issue. Looking at the master node's System Information view shows a problem with the user.name system property :

user.name is fine on the slave's system information though, and assumed the plugin would have retrieved the property from the slave or the agent the job is specified to run on.

Regardless, this is probably an issue for the jenkins/docker project. There's been similar issues and will most likely also be a problem on instances where slaves are not used.

I'm quite ignorant about how Jenkins plugins work, so please close this ticket if no workarounds are possible from this side.

[mercuriete]

Same problem but I think some of this variables are not properly set GRADLE_USER_HOME HOME ANDROID_SDK_HOME

I am trying to get it working I will write here if I could succeed.

(The problem with docker in my case, the user is not in /etc/passwd so when the container is started with an unprivileged user with uid=1005, there are no HOME and of course there are no ANDROID_SDK_HOME)

so fixing the problems with the sdk, I think you can get rid of this question mark "/?/.crashlytics" and you can continue the instalation in the normal $HOME/.android/.crashlytics folder.

[mercuriete]

I couldn't find the root problem but my workaround was creating a question mark folder before compile the project.

mkdir -p ?

Not a good solution but it just works for me.

in your case you need to set GRADLE_USER_HOME for gradle cache and artifacts HOME if is not set ANDROID_SDK_HOME if is not set

and then check what is the new folder that is complaining crashlitics and then create a question mark folder there. The problem with docker+jenkins is jenkins inject the workspace in a volume and runs the container with a non privileged user... and crashlitics is trying to create a folder on / and you dont have permission to do so.

this is part of my pipeline:

        stage('compile') {
            steps {
                //we need to set some variables that are needed to be set for android sdk to work
                withEnv(["GRADLE_USER_HOME=${WORKSPACE}", "HOME=${WORKSPACE}", "ANDROID_SDK_HOME=${WORKSPACE}"]) {
                    //a workaround for firebase's crashlytics gradle plugin to work
                    sh 'mkdir -p ?'
                    //for now only compile on release mode
                    //in the future we would want to run test
                    sh './gradlew assembleRelease --stacktrace'
                }
            }
        }

[mjsobremonte]

Just to follow up, I couldn't spend days on this issue so eventually just fell back to using fastlane (https://fastlane.tools/). Works like a charm with Jenkins pipelines and decouples the dependency from this outdated Jenkins plugin. Also Fabric has somewhat recommended it as an alternate solution: https://stackoverflow.com/a/47272009 Slight caveat is the Ruby dependency, but we easily manage that via RVM.