I am building a shared library that is used to run pipeline on jenkins.
Frequently I used things like:
def call(String stage_name = "Generate installer") {
//noinspection GrUnresolvedAccess
stage(stage_name) {
...
}
}
stage is a Jenkins steps. It generate an "unresolved access" warning in IntelliJ because it's not declared everywhere. Hopefully it does not generate an error as if it was a missing class import.
However I do wonder if there's a better solution than putting suppress warning declarations. Is there any way to indicate to IntelliJ the existence of the Jenkins steps ?
Related
When I use gradle clean build publishToMavenLocal with
publishing {
publications {
maven(MavenPublication) {
from components.java
}
}
}
using gradle 7.1.
It works on local gradle build. However, when I run on Jenkins, I get:
org.jenkinsci.plugins.workflow.steps.MissingContextVariableException: Required context class hudson.FilePath is missing
Perhaps you forgot to surround the code with a step that provides this, such as: node
When, I comment out the publishing section in build.gradle it works in Jenkins.
Any ideas?
Thanks
Publishing to Maven local requires disk space, or working space.
Based on: https://support.cloudbees.com/hc/en-us/articles/4402585187483-How-to-troubleshoot-hudson-FilePath-is-missing-in-a-Pipeline-run
I've put together a basic Jenkins pipeline and it does what I expect for the most part.
However, I'm using ant and it requires access to specific jar files. I've specified the build step like so:
stage('Build') {
// Build the project
env.PATH = "${tool 'ant'}/bin:${env.PATH}"
sh 'ant -f dita-tools/build_all.xml -lib $WORKSPACE/dita-ot/lib:$WORKSPACE/dita-ot/lib/saxon'
}
The build I run through this pipeline fails and generates the following error:
java.lang.ClassNotFoundException: org.dita.dost.module.GenMapAndTopicListModule
From what I can tell, this is due to ant not having access to dost.jar that is in the dita ot. I've tried defining this argument a number of ways including specifically referencing dost.jar (I have a number of jars to include) but every time it fails with the same error.
When I put together a stand-alone ant project in Jenkins, ant has no problem accessing the jar by way of the argument I provide above. Is there a better way for me to supply this argument/dependency in a pipeline?
UPDATE:
I added an echo statement for the classpath to my build script and was able to verify that adding the jars to the classpath in the build script does in fact work. So, for all intents and purposes, ant has access to all the relevant base toolkit jars for the target but the error persists. At this point, it appears that the problem has something to do with how the jenkins pipeline works as opposed to the dita ot itself?
I assume you use custom plugins, if yes, please make sure, you correctly defined your jars in the plugin.xml like so:
<feature extension="dita.conductor.lib.import" file="lib/my.jar"/>
UPDATE
java.lang.ClassNotFoundException: org.dita.dost.module.GenMapAndTopicListModule
This error means, that the main DITA-OT jar is not found on your classpath. So this indicates, that this is not a plugin issue.
Usually you don't have to setup the classpath, Ant does that for you. Please also read Creating an Ant build script.
Please try a snippet like this one:
node {
try {
checkout scm
stage('Build') {
sh '''
dir=$(pwd)
curl [your-dita-ot-url] --output dita-ot.zip
unzip -qq "$dir/dita-ot.zip"
rm dita-ot.zip
chmod +x ${WORKSPACE}/dita-ot/bin/ant
${WORKSPACE}/dita-ot/bin/ant -f ${WORKSPACE}/build.xml -Ddita.dir=$dir/dita-ot -Dbranch.name=$BRANCH_NAME
'''
}
} catch (e) {
currentBuild.result = "FAILED"
throw e
} finally {
notifyBuild(currentBuild.result)
}
}
I am currently trying to transform my former "GUI"-build-steps into a pipeline groovy script. I formerly had a step from the valgrind plugin to publish the results of a valgrind run.
I found the "step: General Build Step" function in the Pipeline Syntax Snippet Generator and tried to use it to create the valgrind publish results step with the following code:
// file pipeline.groovy
import org.jenkinsci.plugins.valgrind.*;
...
node('Publish Valgrind results')
{
step([$class: 'ValgrindPublisher', ValgrindPublisherConfig: [$class: 'ValgrindPublisherConfig', pattern: 'CppCodeBase/Generated/ValgrindOutput/**']])
}
...
When I run this jenkins complains:
java.lang.UnsupportedOperationException: no known implementation of interface jenkins.tasks.SimpleBuildStep is named ValgrindPublisher
So I am not sure if the problem is that ValgrindPublisher only derives from BuildStepand not from SimpleBuildStepor if my import is faulty.
The more general question would be:
Is it possible to run any build-step from a plugin in a pipeline script and if so, where can I find examples?
No you cannot. You can only use steps from pipelines-compatible plugins and it appears that your ValgrindPublisher plugin is not (yet) pipeline-compatible.
You can check this answer for similar information.
Documentation for the Groovy Plugin of Jenkins states that
The system groovy script, OTOH, runs inside the Jenkins master's JVM.
Thus it will have access to all the internal objects of Jenkins, so
you can use this to alter the state of Jenkins. It is similar to the
Jenkins Script Console functionality.
Yet I find that I have a groovy script that I can successfully run in Jenkins Script Console but which does NOT run if entered as a "System Groovy Script" on a build configuration. There are compiler errors. Clearly, the Jenkins Script Console is running with a different classpath than the script in my build. But I can't find information on what the default classpath is when running a script for a build or what the classpath is when running from the Script Console, so I might duplicate that for my script.
Also, the plugin offers a classpath entry field for running the script as a file but that option does not exist for entering the script as text.
I can't get my script to work either way.
What am I missing?
I think the answer is that the Script Console auto-imports the whole Jenkins library. That is not the case with the System Groovy Script. So what worked for me was to run the script, and for every compiler error about an unknown class, add an import statement for that class. I learned what packages they were from by looking at Javadocs.
Automating this would be a nice improvement to the plugin.
May be use the grab dependency management to resolve the library to add
I previously posted this, but I think it's best if I rephrase the issue, as I've gotten no useful response from this or any of the other places I've tried to ask about this.
I'm attempting to use a couple of existing JAXB extensions while generating classes from XJC. This processing has been working fine for a long time in a Maven build, using the "cxf-xjc-plugin". I'm attempting to convert this build to Gradle, but I'm finding that all the other strategies besides the Maven build are failing with the same error, which is something like this:
Caused by: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider com.sun.tools.xjc.addon.xew.XmlElementWrapperPlugin not a subtype
at com.sun.tools.xjc.Options.findServices(Options.java:957)
at com.sun.tools.xjc.Options.getAllPlugins(Options.java:374)
at com.sun.tools.xjc.Options.parseArgument(Options.java:688)
at com.sun.tools.xjc.Options.parseArguments(Options.java:809)
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:474)
at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:457)
at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380)
at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
I can demonstrate this with a single simple Gradle build script. It doesn't require any source code or schemas to compile, the error happens while setting up the classpath.
Note that although the error here references the "Element Wrapper" plugin, if I remove that jar from the classpath, I get the same error, but instead referencing the other JAXB extension, the "Fluent API" extension. As far as I know, I'm referencing recent versions of both of these extensions, and recent versions of the XJC and related jars.
My current simple test case Gradle script is this (I'm calling it "testxjc.gradle"):
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'
sourceCompatibility = 1.7
targetCompatibility = 1.7
repositories {
maven { url "http://repo1.maven.org/maven2/" }
}
configurations {
jaxb
}
dependencies {
jaxb 'com.sun.xml.bind:jaxb-xjc:2.2.7'
jaxb "com.github.jaxb-xew-plugin:jaxb-xew-plugin:1.4"
jaxb "net.java.dev.jaxb2-commons:jaxb-fluent-api:2.1.8"
}
task processXSDs() << {
URLClassLoader loader = GroovyObject.class.classLoader;
configurations.jaxb.each { File file -> println file; loader.addURL(file.toURI().toURL()) }
ant.taskdef(name: 'xjc', classname: 'com.sun.tools.xjc.XJCTask',
classpath: configurations.jaxb.asPath)
ant.xjc(destdir: 'tmp', package: "com.att.sunlight.service.domain.serviceCallResults", extension: true) {
schema(dir: "src/main/resources/schema", includes: "serviceCallResults.xsd")
arg(value: "-Xxew")
arg(value: "-summary target/xew-summary.txt")
arg(value: "-instantiate lazy")
arg(value: "-Xfluent-api")
}
}
compileJava.dependsOn processXSDs
I run this with "gradle -b testxjc.gradle build --stacktrace"
I've also been able to demonstrate the same error by bypassing the Ant task and directly using the XJCFacade class. This requires having the required jars available to reference. Here is my current test script (change semicolons to colons in the classpath if you test this on Linux):
#! /bin/bash
java -classpath "lib/commons-beanutils-1.7.0.jar;lib/commons-lang-2.2.jar;lib/commons-logging-1.1.1.jar;lib/istack-commons-runtime-2.16.jar;lib/jaxb2-basics-runtime-0.6.5.jar;lib/jaxb2-basics-tools-0.6.5.jar;lib/jaxb-api-2.2.7.jar;lib/jaxb-core-2.2.7.jar;lib/jaxb-fluent-api-2.1.8.jar;lib/jaxb-xew-plugin-1.4.jar;lib/jaxb-xjc-2.2.7.jar" com.sun.tools.xjc.XJCFacade -extension
I've tested this on both Win7 and CentOS.
Update:
I now have a clue or two.
First, when I said I tested this on both Win7 and CentOS, I was referring to the shell script. Up to that point, I hadn't run the minimal Gradle build script on CentOS. When I ran this minimal Gradle build script on CentOS, it succeeded (which means, it complained about the missing schema). Besides different OSes, I have different versions of Gradle and Java on each box. I'm in the process of swapping those versions around to see what other clues I can find.
I also got a reply to the post I made to the "jaxb-dev" mailing list, where someone said that they've seen this symptom, and they think it might happen when multiple JAXB jars are found on the classpath, and some JAXB classes are loaded by one classloader, and other JAXB classes by another.
From this input, I suppose I should try running my minimal test with verbose classloading and see how they differ, but I'm not sure I'll be able to see what I need through all the noise that will produce.