Shared groovy library frustration

[Peter Berghold]

Here is a tree of a very simple "library" I set up:

├── build.xml

├── manifest.mf

├── nbproject

│   ├── build-impl.xml

│   ├── genfiles.properties

│   ├── groovy-build.xml

│   ├── private

│   │   ├── config.properties

│   │   ├── private.properties

│   │   └── private.xml

│   ├── project.properties

│   └── project.xml

└── src

    ├── net

    │   └── berghold

    │       └── MainTest.groovy

    └── SimpleGroovyScript.groovy

Most important of which is under "src" with the class MainTest 

Here is the class itself:

/*

 * To change this license header, choose License Headers in Project Properties.

 * To change this template file, choose Tools | Templates

 * and open the template in the editor.

 */

package net.berghold

/**

 *

 * @author peter

 */

class MainTest implements Serializable {

def Object context

        

    def void runme(){

        context.sh('echo foobar')

    }

}

so far nothing earth shattering.  I've set up this shared library in the main Jenkins setup menu.   Should be groovy so far  but it isn't

Here is a simple pipeline I set up to test this:

import net.berghold.MainTest

node('master'){

    step('run test'){

        def MainTest mt = new MainTest(context: this)

        

        mt.runme()

    }

}

When I try to "build" this I get the following error to the console:

Running in Durability level: MAX_SURVIVABILITY
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 1: unable to resolve class net.berghold.MainTest
 @ line 1, column 1.
   import net.berghold.MainTest
   ^

1 error

to me that implies the library is not being loaded for reasons I just don't get.

Things I tried:

I actually told it to implicitly load this library but it now complains that it needs a version.  I told it "master" and it claims it can't find that version.   I tried */master refs/master and a few other things I know exist and the error came back that it could not validate the version with a null pointer error under the details.

Has this functionality been broken? 

Running Jenkins 2.147.   This all used to work.  This example is a pared down version and the original shared libs that worked no longer work and I'm a bit concerned.

[Jan Monterrubio]

Are you missing the @Library import in your pipeline?  Or does your shared library have a load implicitly declared?

https://jenkins.io/doc/book/pipeline/shared-libraries/

--
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 jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAArvnv3tBnk9B3Xm4Z2vug%2BNCv92822k5H70xRm_%3D-DW7jdhKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Berghold]

Interestingly enough on a Jenkins server i manage where I have working shared libraries (multiple) I don't use the @Library form at all.  I tried it on this other Jenkins server (the one I'm trying to *get* working) and it didn't work.

In my first attempt I simply used:

@Library('lib3') _       

which I saw in this documentation: https://jenkins.io/doc/book/pipeline/shared-libraries/

that yielded me the following errors

ERROR: No version specified for library lib3
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: Loading libraries failed

OK fine,  I'll add a version to it which according to the cited page above can be a branch and "master" is certainly a branch. 

@Library('lib3@master') _ 

Using that gave me more errors

Loading library lib3@master
java.lang.NullPointerException
	at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.retrieve(SCMSourceRetriever.java:82)
	at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:157)
	at org.jenkinsci.plugins.workflow.libs.LibraryAdder.add(LibraryAdder.java:138)
	at org.jenkinsci.plugins.workflow.libs.LibraryDecorator$1.call(LibraryDecorator.java:125)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1065)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
	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.doParse(CpsGroovyShell.java:131)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:317)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429)
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: Loading libraries failed

So what I'm wondering at this point, is there a plugin I'm missing?   What plugins are necessary to run Groovy pipelines including shared libraries?  

I'm stumped here... and grasping at straws. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CADgiF9KYK0pAY5bvo%2BdXEVW8mAZ2nx%3DNGOhyggwKdm1ajGXp5w%40mail.gmail.com.

[Peter Berghold]

OK... seems this is somehow related to https://issues.jenkins-ci.org/browse/JENKINS-45260

is there at least  a work-around?  

[Peter Berghold]

Not sure if this is really what fixed the problem but here goes:

Destroyed the Docker instance running my Jenkins installation and rebuilt it using LTS instead of the "latest and greatest bleeding edge" version. Docker is a good thing that way. :-)

Now have a stripped down version and my simple shared library now works.  I'll move on to more complicated ones next.  Is this a problem with the version I was using <shrug> dunno.