Jenkins 2.176.4-3 rolling
Gradle 4.3.1
Issue area: Parallel run of a gi
At a single pipeline run case, if you have even more projects (let's say 20+ projects) and you are running Gradle someTask in parallel (whether in a single stage or individual stages per project), then you could set GRADLE_USER_HOME=$WORKSPACE/${whichProject} folder (where ${whichProject} is a project folder which will be available to you in Jenkins WORKSPACE (after git clone or similar checkout operation)). This could possibly solve any parallel task running into any locking related issues but at the cost of compromising Gradle's performance (i.e. for not using Gradle CACHE among many project's parallel task run).
Setting a unique GRADLE_USER_HOME value (per project) inside dynamically created unique Jenkins workspace (example: /jenkins/workspaces/jobname/<buildnumber>/ where BUILD_NUMBER makes the Jenkins workspace folder unique) will resolve any lock related issues
GRADLE_USER_HOME=/jenkins/workspaces/jobname/<buildnumber>/Project1 (and now .gradle and caches folders will sit under this folder and used by Gradle and won't collide with other project's Gradle CACHE folder: .gradle and caches which are also running in parallel).I noticed CLI option --gradle-user-home (aka $GRADLE_USER_HOME) while running Gradle task was getting set to just Jenkins's WORKSPACE example value only and thus, all 3-5 project's Gradle task (in my case rpm task) runs were running in parallel (using the same service account's Gradle caches folder) which usually sits under GRADLE_USER_HOME location (so in my case single Gradle's caches folder was getting shared by all those 3-5 projects for parallel task run).
I'm still trying to find the solution for When running concurrent pipeline runs (which again runs parallel Gradle rpm task per project within a single pipeline run) each using their own different Jenkins WORKSPACE folders, why I'm still getting these issues; I'll update if I find a solution.