Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38517

“Local module directory” not supported for external libraries

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: subversion-plugin
    • Labels:
    • Environment:
      LTS 2.7.4

      scm-api 1.3
      subversion 2.6
      worfklow-cps-global-lib 2.3

      Zulu OpenJDK 8.17.0.3-win64 (1.8.0_102-b14)
      Win 7 Pro master--error does not involve agents
    • Similar Issues:

      Description

      Multiple shared libs throw "ERROR: Library <lib name> expected to contain at least one of src or vars directories" when multiple external SVN Legacy SCM libs are loaded by the Jenkinsfile and the Local module directory indicates preservation/overriding of the parent directory. (Ie, when the dot default is not used and a working copy root directory for each lib is created under the @libs directory.

      Configuration of global and folder specific libraries as shown in the attachments. The Jenkinsfile script begins

      @Library('pipeline_global_helpers') _
      
      @Library('pipeline_branch_build')
      import com.foo.bar.Application
      

      Running the pipeline makes it as far as checking out or updating the local working copies in the @libs/pipeline_global_helpers and @libs/pipeline_branch_build in the pipeline workspace on the master, but execution aborts thereafter with the stack trace

      ERROR: Library pipeline_branch_build expected to contain at least one of src or vars directories
      org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
      WorkflowScript: Loading libraries failed
      
      1 error
      
      	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
      	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1073)
      	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
      	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
      	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
      	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
      	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
      	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
      	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
      	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
      	at hudson.model.ResourceController.execute(ResourceController.java:98)
      	at hudson.model.Executor.run(Executor.java:410)
      Finished: FAILURE
      

      The libraries both have src and vars subdirectories and cause no error if used individually if checked out with Local module directory set to the default dot (no working copy root directory). I have also avoided the error once or twice when overriding/preserving the working copy root directory when loading a single external library, but not reliably. Ultimately the above error recurs.

      Checking out straight into the @libs directory is good for the single-library use case but if I attempt to use multiple libraries, the first checkout's working copy is blown away by the second library's checkout.

      For now, my workaround is to use a single external library.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Ah, that indeed looks like a mistake; it should be using a distinct workspace per library.

            Show
            jglick Jesse Glick added a comment - Ah, that indeed looks like a mistake; it should be using a distinct workspace per library.
            Hide
            jglick Jesse Glick added a comment -

            Submitted a proposed fix for that.

            Show
            jglick Jesse Glick added a comment - Submitted a proposed fix for that.
            Hide
            brianeray Brian Ray added a comment -

            Thank you. I'm still for suppressing Local module directory from the UI in this context, too.

            Show
            brianeray Brian Ray added a comment - Thank you. I'm still for suppressing Local module directory from the UI in this context, too.
            Hide
            brianeray Brian Ray added a comment -

            The patch in worflow-cps-global-lib 2.5 speeds up non-initial library checkouts considerably. Thanks.

            Show
            brianeray Brian Ray added a comment - The patch in worflow-cps-global-lib 2.5 speeds up non-initial library checkouts considerably. Thanks.
            Hide
            jons Jon Sten added a comment -

            Just a short note, I created JENKINS-40408 which is a bug introduced due to workflow-cps-global-lib PR 18 which was made to fix this issue.

            Show
            jons Jon Sten added a comment - Just a short note, I created JENKINS-40408 which is a bug introduced due to workflow-cps-global-lib PR 18 which was made to fix this issue.

              People

              • Assignee:
                Unassigned
                Reporter:
                brianeray Brian Ray
              • Votes:
                2 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: