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

“Local module directory” not supported for external libraries

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • subversion-plugin
    • 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

      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.

          [JENKINS-38517] “Local module directory” not supported for external libraries

          Brian Ray created issue -
          Brian Ray made changes -
          Attachment Original: firefox_2016-09-23_13-52-40.png [ 34080 ]
          Brian Ray made changes -
          Attachment New: firefox_2016-09-26_13-10-08.png [ 34081 ]

          Jesse Glick added a comment - - edited

          External libraries mandate that src/ etc. be at the root of a “repository”, which in the case of Subversion would be a “version” folder such as …/trunk/, so it is correct to fail. Possibly it could fail with a more helpful error message, though I am not sure that is feasible—would have to look at what the API offers in this case.

          Jesse Glick added a comment - - edited External libraries mandate that src/ etc. be at the root of a “repository”, which in the case of Subversion would be a “version” folder such as …/trunk/ , so it is correct to fail. Possibly it could fail with a more helpful error message, though I am not sure that is feasible—would have to look at what the API offers in this case.
          Jesse Glick made changes -
          Description Original: ... 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

          {quote}@Library('pipeline_global_helpers') _

          @Library('pipeline_branch_build')
          import com.foo.bar.Application
          {quote}

          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

          {quote}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{quote}

          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.
          New: 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

          {code}
          @Library('pipeline_global_helpers') _

          @Library('pipeline_branch_build')
          import com.foo.bar.Application
          {code}

          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

          {code:none}
          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
          {code}

          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.

          Jesse Glick added a comment -

          Really I think Local module directory should be hidden in an Advanced block so that people are not tempted to use it.

          Not possible for workflow-cps-global-lib to even detect that it is in use, since SCM.getModuleRoots is limited to AbstractBuild. In principle the core API could be extended, but I think it is not worth the effort for a legacy feature like this.

          Jesse Glick added a comment - Really I think Local module directory should be hidden in an Advanced block so that people are not tempted to use it. Not possible for workflow-cps-global-lib to even detect that it is in use, since SCM.getModuleRoots is limited to AbstractBuild . In principle the core API could be extended, but I think it is not worth the effort for a legacy feature like this.
          Jesse Glick made changes -
          Component/s Original: workflow-cps-global-lib-plugin [ 21714 ]
          Labels New: pipeline
          Summary Original: Multiple shared libs throw "ERROR: Library <lib name> expected to contain at least one of src or vars directories" when ... New: “Local module directory” not supported for external libraries

          Brian Ray added a comment -

          This makes sense jglick. If I restructure the directory tree for these libraries in our SVN repo, I might be able to get what I am after. Thanks.

          Brian Ray added a comment - This makes sense jglick . If I restructure the directory tree for these libraries in our SVN repo, I might be able to get what I am after. Thanks.

          Brian Ray added a comment -

          FWIW and if it helps anybody else running up against a similar issue, the SVN server where we store our Pipeline and other CD projects is not organized such that the branch is the last component of the of the path to the source, e.g. .../cool-pipeline-proj/trunk, rather the branch portion(s) are further up the directory hierarchy a la /department/trunk/bunch-of-general-folders/../proj and the even trickier /department/branches/bunch-of-general-folders/../cool-pipeline-proj/version. That may or may not be apparent up in the screenshots.

          The more I think about it, the more I want to clean the directory hierarchy for these external libs. At the least I will attempt it to see if multiple libs function correctly.

          Brian Ray added a comment - FWIW and if it helps anybody else running up against a similar issue, the SVN server where we store our Pipeline and other CD projects is not organized such that the branch is the last component of the of the path to the source, e.g. .../cool-pipeline-proj/trunk , rather the branch portion(s) are further up the directory hierarchy a la /department/trunk/bunch-of-general-folders/../proj and the even trickier /department/branches/bunch-of-general-folders/../cool-pipeline-proj/version . That may or may not be apparent up in the screenshots. The more I think about it, the more I want to clean the directory hierarchy for these external libs. At the least I will attempt it to see if multiple libs function correctly.
          Brian Ray made changes -
          Attachment New: firefox_2016-10-05_12-37-41.png [ 34250 ]

            Unassigned Unassigned
            brianeray Brian Ray
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: