I have commented out this very line and have seen situation improve. Basically, this line
rm -rf /var/lib/jenkins/.gradle/caches
existed for historical reasons, which I’m unaware of and nobody in the company knows. A guess would be as follows:
stages {
stage(‘clean’) {
steps {
script {
try {
echo ‘Current Branch…’ + env.BRANCH_NAME
//sh ‘rm -rf /var/lib/jenkins/.gradle/caches’
sh ‘./gradlew clean --stacktrace’
} catch (e) {
currentBuild.result = ‘FAILURE’
slackHelper.buildGenericJobFailureNotificationMessage()
throw e
}
}
}
}
AFAIK,
gradlew clean
only clears the build directory. Maybe the original author felt the strong need for clearing the global cache because some of the jars (libraries) in use are updated internally quite frequently and not clearing the global cache would result in not having right dependency version in the classpath. For various reasons, including but not limited to :
1/ poor versioning strategy
2/ unclear release model
we add these dependencies in build.gradle as below:
> dependencies {
> compile "com.xyz:model:+"
> compile "com.xyz:apiConnector:+"
> compile "com.xyz:service:+"
> }
I also have disabled use global cache for now.
The plan now is to
a. Enable global cache.
b. (if a fails) configure project specifc cache.
@Stefan_Wolf my questions for you:
- Do you see any issue with #b?
- When and how does gradle decides to refresh global cache? [I could not conclusively decide on this looking at the documentation. If I missed something, please point me to the right link]