-
Bug
-
Resolution: Unresolved
-
Major
-
CloudBees Jenkins Enterprise 2.89.4.2-rolling
Pipeline: Groovy (workflow-cps): 2.47
Pipeline: Shared Groovy Libraries (workflow-cps-global-lib): 2.9
P4 Plugin (p4): 1.7.3-DRE1.25
Operating System: CentOS release 6.7 (Final)
Java version: java version "1.8.0_131" , Java(TM) SE Runtime Environment (build 1.8.0_131-b11)CloudBees Jenkins Enterprise 2.89.4.2-rolling Pipeline: Groovy (workflow-cps): 2.47 Pipeline: Shared Groovy Libraries (workflow-cps-global-lib): 2.9 P4 Plugin (p4): 1.7.3-DRE1.25 Operating System: CentOS release 6.7 (Final) Java version: java version "1.8.0_131" , Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
We're encountering an issue where multiple jobs syncing a groovy shared library concurrently results in the wrong sync root being used for some of the jobs. For example, job1 and job2 are triggered at the same time and use the p4 plugin for syncing the groovy shared library. job1 will have the correct workspace root (e.g. /var/lib/jenkins/jobs/job1/workspace%40libs/LIBRARYNAME) for the groovy shared library sync, but job2 will sync the groovy shared library to the same workspace root as job1 (e.g. /var/lib/jenkins/jobs/job1/workspace%40libs/LIBRARYNAME). When job2 loads the groovy shared library, it references what the workspace root should be for job2 (e.g. /var/lib/jenkins/jobs/job2/workspace%40libs/LIBRARYNAME), which was not sync'd to, and causes job2 to run based off of an old groovy shared library sync.