Jenkins无法解决全局共享库的依赖关系

时间:2019-03-14 19:15:28

标签: jenkins gradle groovy jenkins-pipeline

我正在尝试使用Jenkinsfile建立一个Jenkins管道,该管道从自我实现的全局共享库中调用方法,其中的@Library("name-of-library")位于Jenkinsfile的开头。

但是,我正在使用的库是由Gradle组织的一个常规项目。也就是说,在定义依赖项的库的整个存储库的根目录处都有一个build.gradle

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.15'
    compile group: 'commons-io', name: 'commons-io', version: '2.6'
    compile group: 'eu.agno3.jcifs', name: 'jcifs-ng', version: '2.1.1'
    compile group: 'org.slf4j', name: 'slf4j-api', version: '1.8.0-beta4'
    testCompile 'junit:junit:4.12'
    testCompile 'org.mockito:mockito-all:1.9.5'
    testCompile group:'com.lesfurets', name:'jenkins-pipeline-unit', version:'1.0'
}

当我们基于上面提到的管道触发构建时,我们发现Jenkins可能无法识别build.gradle,从而导致以下错误:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
file:/var/lib/jenkins/jobs/test-pipeline/builds/4/libs/name-of-library/src/com/test/model/SMBConnection.groovy: 4: unable to resolve class jcifs.context.BaseContext
 @ line 4, column 1.
   import jcifs.context.BaseContext
   ^

file:/var/lib/jenkins/jobs/test-pipeline/builds/4/libs/name-of-library/src/com/test/model/SMBConnection.groovy: 5: unable to resolve class jcifs.config.BaseConfiguration
 @ line 5, column 1.
   import jcifs.config.BaseConfiguration
   ^

file:/var/lib/jenkins/jobs/test-pipeline/builds/4/libs/name-of-library/src/com/test/model/SMBConnection.groovy: 3: unable to resolve class jcifs.CIFSContext
 @ line 3, column 1.
   import jcifs.CIFSContext
   ^

3 errors

    at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
    at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:958)
    at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:605)
    at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:554)
    at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
    at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
    at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:254)
    at groovy.lang.GroovyClassLoader.recompile(GroovyClassLoader.java:761)
    at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:718)
    at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:787)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
    at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell$TimingLoader.loadClass(CpsGroovyShell.java:158)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
    at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:677)
    at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:545)
    at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:185)
Caused: BUG! exception in phase 'semantic analysis' in source unit 'WorkflowScript' The lookup for com.test.controller.factory.CustboxFacadeFactory caused a failed compilaton. There should not have been any compilation from this call.
    at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:190)
    at org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:170)
    at org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:126)
    at org.codehaus.groovy.control.ResolveVisitor.resolveToOuter(ResolveVisitor.java:676)
    at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:313)
    at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1245)
    at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:176)
    at org.codehaus.groovy.control.CompilationUnit$12.call(CompilationUnit.java:663)
    at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:943)
    at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:605)
    at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:554)
    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:320)
    at hudson.model.ResourceController.execute(ResourceController.java:97)
    at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

我尝试使用grape表示法将这些依赖项添加到Jenkinsfile的顶部。

@Grapes([
  @Grab(group='commons-io', name='commons-io', version='2.6'),
  @Grab(group='eu.agno3.jcifs', name='jcifs-ng', version='2.1.1'),
  @Grab(group='org.slf4j', name='slf4j-api', version='1.8.0-beta4')
])

但是,这无济于事。 由于我正在使用的库包含数百个groovy文件,因此我认为在每个groovy文件的开头添加葡萄符号不是一个好主意。

我还尝试将build.gradle转换为pom.xml并将其放在库回购的根目录中。但是,它也无济于事。

是否有什么我可以尝试的方法,而无需将管道步骤重写为gradle任务并在Jenkinsfile中使用sh('./gradlew task-name')

0 个答案:

没有答案