You are probably farther along than me as I have not even looked at the code, but what I am observing on my end is this:
There is a some sort of a shared location, in my case "workspace@libs/" directory, which seems to house the repo (note that name of the library is not there), and then inside individual builds there is a lib/<name>/ directory which contains the snapshot in time of the library that is actually used for this build. I am using git, so there is a git repo in the first place, but only the files in the build - but I suspect there is a similar thing for svn A few things that I see here that are different in your case: 1 - Your workspace is not named "workspace@libs" but is instead named "x-pipeline-1@libs" - not sure if this is a per-build directory, or a shared repo dir 2 - If #1 is your shared directory, you have an extra subdirectory in there. Try searching for "cmd.groovy" under your job directory and see where all the copies are. See where there is a .svn dir vs where there is just a copy and make sure that it is in the right place. -M On Friday, September 16, 2016 at 5:03:13 PM UTC-7, Brian Ray wrote: > > All good tips. I've been blowing away the local copy between attempts and > currently have this structure (note: I changed the configured libname from > *helpers > *to *pipelineGlobalHelpers *in the latest attempt, and this is checking > out on my local troubleshooter master right now--this is even before the > first *stage *or *node *blocks): > > c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\pipelineGlobalHelpers> > dir > Volume in drive C has no label. > Volume Serial Number is 4456-EE0F > > Directory of c:\Jenkins\workspace\Dev-Snippets\x-pipeline-1@libs\ > pipelineGlobalHelpers > > 2016-09-16 16:18 <DIR> . > 2016-09-16 16:18 <DIR> .. > 2016-09-16 16:18 <DIR> resources > 2016-09-16 16:18 <DIR> src > 2016-09-16 16:18 <DIR> vars > 0 File(s) 0 bytes > 5 Dir(s) 249,994,575,872 bytes free > > > This > <https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/1b70381dbda34e6fd9acb15b4c206e9aec75c965/src/main/java/org/jenkinsci/plugins/workflow/libs/LibraryAdder.java#L147-L183> > > is likely the method that's complaining; see the *throw *at the end. > > The thing that I am puzzling at is the construction of the directory path: > > FilePath libDir = new FilePath(execution.getOwner().getRootDir()).child( > "libs/" + name); > > That to me suggests it yields > c:/Jenkins/workspace/Dev-Snippets/x-pipeline-1/libs/pipelineGlobalHelpers, > instead of .../x-pipeline-1@libs/pipelineGlobalHelpers, but maybe I am > misunderstanding *FilePath#child* or *#getRootDir*. > > There are still a few more experiments to try. > > > On Friday, September 16, 2016 at 4:28:05 PM UTC-7, Michael Lasevich wrote: >> >> Implicit load was to work around issues with '@Library' syntax, but I >> doubt that is your issue here. >> >> I would check that your SVN URL is pointing to directory that has "vars" >> in it and double-check that it is checking out the right dir. Look for >> "vars" dir in <job>/workspace@libs/ dir in yours job and/or >> "<job>/builds/##/libs/helpers/" inside your specific build) >> >> I would also maybe wipe the local cache of the svn repo and force a full >> checkout again. >> >> -M >> >> On Friday, September 16, 2016 at 4:12:43 PM UTC-7, Brian Ray wrote: >>> >>> >>> <https://lh3.googleusercontent.com/-lo8y6lCOagw/V9x6kpax5UI/AAAAAAAAAQo/z44qH8va24Y22p7rhBE6kwnpMvMUj3MCgCLcB/s1600/firefox_2016-09-16_15-53-14.png> >>> >>> You beat me to the post. The hyphen in the lib name *is* causing the >>> failure to interpolate, much the same as it would in Groovy GString >>> interpolation. (Though I think the mechanism here is different, since >>> plugins are written in Java ... ) >>> >>> The above lib config fixed the interpolation problem. But the vars/ and >>> src/ subdirectory discovery issue pops up again. >>> >>> Started by user Brian Ray <http://cic-qa-ber:8080/user/brian66481> >>> Loading library helpers@trunk >>> Updating >>> https://XXXXXXXXXXXXXXXXXXXXXX/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers >>> >>> <https://cic-svr-svn01.landacorp.local:18080/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers> >>> at revision '2016-09-16T15:50:21.511 -0700' >>> At revision 85052 >>> >>> No changes for >>> https://XXXXXXXXXXXXXXXXXXXXXXXXXX/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers >>> >>> <https://cic-svr-svn01.landacorp.local:18080/svn/releng/trunk/retools/pipeline-global-libs/pipeline-global-helpers> >>> since the previous build >>> ERROR: Library helpers expected to contain at least one of src or vars >>> directoriesorg.codehaus.groovy.control.MultipleCompilationErrorsException >>> <http://stacktrace.jenkins-ci.org/search?query=org.codehaus.groovy.control.MultipleCompilationErrorsException>: >>> startup failed: >>> WorkflowScript: Loading libraries failed >>> >>> 1 error >>> >>> at >>> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310) >>> [...] >>> >>> >>> >>> I bet there is something finicky about the root directory of the SVN >>> working copy. But I will give *Load implicitly* a shot too. >>> >>> Thanks >>> >>> On Friday, September 16, 2016 at 3:31:07 PM UTC-7, Michael Lasevich >>> wrote: >>>> >>>> Is it possible that this is some odd issue with '-' symbols in the >>>> library name? I would try a simpler name. Also try to implicit load to >>>> simplify the load... >>>> >>>> -M >>>> >>>> On Friday, September 16, 2016 at 1:16:05 PM UTC-7, Brian Ray wrote: >>>>> >>>>> Evidently I cannot drive this post widget very well. The screenshots >>>>> are best clicked in reverse order, with the last two corresponding to the >>>>> *First >>>>> Try*, the middle two to *Second Try*, and the first two to *First >>>>> Try.* >>>>> >>>>>> >>>>>> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0a39f70b-b37a-47ac-9d21-c6159b02408a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
