I searched around for a while and have not found an answer to this question. I am using Jenkins to do some testing and I use Clearcase as my CM tool. The stylesheet I have created for a custom tool lives in a directory relative to the clearcase view path. When I hardcode the entire path to the stylesheet, everything is fine, but if I try to use the ${CLEARCASE_VIEWNAME} environment variable, xUnit does not try to resolve it, rather it gives me the error that
"The input xsl '${CLEARCASE_VIEWNAME}/rest_of_path/my_stylesheet.xsl' relative to the workspace '/myworkspace' doesn't exist."
The strange thing is that I also use this variable to point to where the xml file is and it finds it with no problem. Does anyone know if that is a specific "feature" of the xUnit plugin or if it is a bug?
See pushy's answer to my other post at Hudson/Jenkins PMD Configuration
Your clearcase path needs to be specified in the main Jenkins configuration.
Bug.
(or unimplemented feature)
I have run into the same scenario using the Jenkins XUnit plugin, where the "Custom Tool Pattern" value containing a Global Parameters IS being resolved, but the "Custom Stylesheet" value containing a Global Parameters is NOT resolved, leading to an error similar to yours.
Having a peek at the source: https://github.com/jenkinsci/xunit-plugin/ reveals that the Global Parameter resolution for the XLS parameter is not yet implemented.
A bug has been filed here: https://issues.jenkins-ci.org/browse/JENKINS-17438/
Since it's open source, it's time to get Maven installed and debug some Jenkins plugin code.
UPDATE: and done, you should see the new functionality in the latest version
Related
How to set the Report File Pattern with Jenkins Warnings Next Generation Plugin when using a groovy parser as a post build action with static analysis tool (Report file pattern has to come for the empty input field in bellow image)
I have tried various methods but none of them worked. Appreciate any valuable input.
This parser examine within the jenkins work space of the project. Therefore when I gave a log file (or any other file type) in the workspace that worked properly. If anyone in the future came across with the same issue hope this could benefit you somehow.
I am not using ANT at all so the proposed duplicate does answer this question about Jenkins.
I am working on a build script that will increment the version number of the program. To do this the version file will be checked out, next version number computed and written back, and then checked in.
It occurs to me that this will trigger yet another build in an endless cycle. When we used TFS builds we could put a string in the check in comment like ***NOCI*** or something and that check in would be ignored and not trigger a new build.
Is there any such option for Jenkins or a technique I can apply myself to solve this?
I am using the TFS plugin to access my SCM.
The Subversion SCM plugin allows you to specify paths that will be excluded when polling for new versions. Git SCM also can be configured to exclude some regions.
By excludng the file that contains the version number you will be able to avoid the vicious circle that you observed.
Since you cannot cloak or .tfignore your versioning file...you can use the NOCIOption property, and pass in the flag for it, in your comments.
You would setup the NOCIOption property of the SyncWorkspace workflow activity in TFS, and during your version change, pass "****NO_CI***" flag in the comments of the checkin. This is kind of hackish and could be avoided if you used GlobalAssemblyInfo.cs versioning, linked throughout your project instead.
I suggest not using your "versioning" file, as it's fundamentally wrong for the reason of cyclic checkins. I would suggest using the GlobalAssemblyInfo.cs linked throughout your .NET solution and stamping that prior to calling MSBuild. It works like a champ for setting and linking versioning throughout your .NET projects in your solution. You implement Global Assembly Info in your solution as described in this answer here.
You can understand more of it here, at "What are the best practices for using assembly attributes". You could simply stamp this file (via Powershell or whatever) and call MSBuild and your version will be present in all .DLLs.
Currently I have a multibranch pipeline job where a build happens and the cppcheck is used to analyse the code. However there is no 'post build actions' tab available available in the multibranch pipeline to enable 'publish cppcheck results'. I have been searching long in the internet for an answer but i am not able to find.
There are only General,Build Triggers,Advanced project options and pipeline tabs available ( i chechked the advanced project options and there is no option to add the post build section there).
Is there a way to hardcode the cppcheck.xml publish using the jenkinsfile itself? Is there any syntax that i can use that will call the cppcheck plugin to check the xml file and publish it. This is really an emergency requirement. I tried searching a lot to convert the xml to other formats like html or jnuit xml . Nothing seems to work. Can someone help?
To do that, I'm using the Jenkins Warnings Plugin with a custom parser.
Since release 3.8 you can define new parsers dynamically in the system configuration section of Jenkins. Just navigate to http://[jenkins-url]/configure and create a new parser in section Compiler Warnings. The UI should be self explanatory
Instead of XML, a text file is generated with this command line:
cppcheck --enable=all --template="{file},{line},{severity},{id},{message}" . 2> cppcheck.txt
Here is the help for the template parameter:
--template='<text>' Format the error messages. E.g.
'{file}:{line},{severity},{id},{message}' or
'{file}({line}):({severity}) {message}' or
'{callstack} {message}'
Pre-defined templates: gcc, vs, edit.
More information can be found in the Cppcheck PDF manual.
I'm using this regular expression to parse the file:
^(.+),(\d+),(error|warning|style|performance|portability|information),(.*),(.*)$
UPDATE
The Warnings Plugin reached end-of-life. All functionality has been integrated into the Warnings Next Generation Plugin.
With this new plugin, cppcheck is supported without the need of a custom parser.
Generate the XML file with this command line:
cppcheck --xml --xml-version=2 . 2> cppcheck.xml
In your Jenkinsfile you will need to add this line to scan the file for warnings or issues:
scanForIssues tool: cppCheck(pattern: 'cppcheck.xml')
Currently the CPPCheck plugin does not support pipeline.
There is however a pull request open for the plugin
https://github.com/jenkinsci/cppcheck-plugin/pull/36
Feel free to clone it and do some more testing.
In november 2017, the pull request mention by JamesD was merged.
If you look at the Pipeline documentation, there is now a htmlpublisher command.
Please note that the xml has to be previously generated and that the pattern argument used below search for the file from the %WORKSPACE% path.
stage('CppCheck') {
steps {
publishCppcheck pattern:'output/bin/Release/report_cppcheck.xml'
}
}
I've spent many hours on this without any success at all. According to this I should be able to use any available SCM but I don't know how to map the paths, where, if anywhere, to insert the ${library.RegLib.version} or what workspace name to use.
I have a library set up as per the abovementioned docs:
<root>/src/org/somelib/MyLib.groovy
which contains:
package org.registration;
def doTest() {
echo "test running..."
}
I've tried many different things but nothing works. I've also tried restarting Jenkins, as mentioned here. No change.
My build reports:
Loading library MyLib##1
java.lang.ArrayIndexOutOfBoundsException: 1
at org.jenkinsci.plugins.p4.tasks.AbstractTask.setEnvironment(AbstractTask.java:106)
at org.jenkinsci.plugins.p4.PerforceScm.checkout(PerforceScm.java:391)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.doRetrieve(SCMSourceRetriever.java:107)
at org.jenkinsci.plugins.workflow.libs.SCMRetriever.retrieve(SCMRetriever.java:63)
at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:150)
at org.jenkinsci.plugins.workflow.libs.LibraryAdder.add(LibraryAdder.java:131)
at org.jenkinsci.plugins.workflow.libs.LibraryDecorator$1.call(LibraryDecorator.java:99)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
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:429)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:392)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:221)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: Loading libraries failed
"Default version" is set to 1 because there's only been one commit. I've also tried #1. I don't know whether to map specific files or the top-level directory. If I remove the default version the build fails and complains that I haven't set a version. It's supposed to be optional but clearly isn't.
I've also tried using the vars directory
<root>/vars/doTest.groovy
which contains:
def call(msg) {
echo msg
}
but I presume that also requires the library to be loaded. The docs are unclear about that.
So...
Will this work with perforce?
How do I map the paths to make it work?
How do I make the code in vars accessible? Is that loaded as part of the overall library?
Is there an error somewhere in my code?
Many thanks.
Install Pipeline Shared Libraries Plugin.
The configuration is in Manage Jenkins -> Global Pipeline Libraries
The retrieval method should be legacy mode. add repository
Tick the Load implicitly to load the scripts in every build
Put the groovy files in vars/yourGroovy.groovy and call it from Jenkinsfile:
yourGroovy()
Seems to be an open issue with the p4 plugin, related to the p4 plugin being unable to deal with perforce checkouts at locations different from the workspace root:
https://issues.jenkins-ci.org/browse/JENKINS-40055
https://issues.jenkins-ci.org/browse/JENKINS-36243
Edit: You may be able to get this to work using older plugin versions, according to the reporter of the first issue:
The crash is not present in version 2.4 of workflow-cps-global-lib, it
started to happen in version 2.5 only.
This is really late, but I was wondering if you found a solution.
In Amityo's answer you commented that your Perforce source path is //<prod>/trunk/src/apps/jenkinslib#${library.RegLib.version}/..., where ${library.RegLib.version} = 1 if no other version is explicitly specified in pipeline.
I think Jenkins will literally look for a folder named jenkinslib#1, which it won't find since your folder is just named jenkinslib.
I don't know how you would set up your structure to support different versions, but maybe having just //<prod>/trunk/src/apps/jenkinslib/... as your source path in the map might work, even though the config page tells you to add library.RegLib.version.
I would've commented all this on Amityo's post instead but I don't have enough reputation to do so.
In reply to #HS10, I did and I've been meaning to update this for the benefit of others for ages but everything else in life seems to become higher priority. Since you've asked, here's what I did.
In Jenkins/Configuration, under Global Pipeline Libraries I set the following:
Specifically, provide a Name and set Default version tohead. Set the Retrieval method to Legacy SCM. Perforce doesn't have Modeern SCM support, yet. Under Source Code Management select Perforce Software. Note that this is the p4 plugin, not the old Perforce one which is listed as Perforce. I suspect that it's important to use the version written by Perforce themselves. Select a Credential that you have configured and provide a matching workspace name and mapping. I may have had that wrong earlier, I don't know. Other settings should be at your discretion. The library directory structure is as per the docs. I did think for a while that the workspace name had to be _global_lib but recent experiments appear to have disproved that.
In your pipeline, import the library like this:
#Library('plib') _
// do something
You should now have a working library.
I think I had this wrong earlier, as well. Note that the underscore is important. See the Global Lirary docs for more details. Getting this working caused me a lot of pain so I hope this saves someone from having a similar experience.
I have a Jenkins job that stores artifacts as a post-build action. Within these artifacts is a text file that tells which version of the software has been built. Is it somehow possible in a Jenkins project to get access to this text file and displaying its contents somewhere on the Jenkins build page somehow? This way the build manager would instantly see what software version this archived artifact contains. Thanks!
There are more advanced ways with GroovyScript, but I can suggest something like this:
Use Description Setter plugin. It uses RegEx to look at the console output (build log) for a pattern and sets the description (as seen in screenshot) accordingly.
If you don't have the version already printed in console log, you can print it out with either
cat filename (Linux) or type filename (Windows). No need to store a version text file as an artifact (unless you need it for other purposes)
To answer your question directly, in order to add text to actual build page, you can use Groovy Postbuild plugin, something like this:
def workspace = manager.build.getEnvVars()["WORKSPACE"]
String fileContents = new File('${workspace}/filename.txt').text
manager.createSummary("folder.gif").appendText("${fileContents }")
The plugin page has a lot of examples.
I got a revised proposal. Since all you really want is to include a semantic versioning information in your displayed build name and/or description, there is a simpler way to do this.
First of all I have stumbled upon a plugin that does the extraction of your version from the Maven or SBT build process quite nicely - the Semantic Versioning Plugin. This does what is advertised - extracting the version from POM or whatever and including this as a file and a variable in your build process. So you have the freedom to use both, either include the file in your build process and do what you heart wishes AND/OR use the variable to affect the build flow in Jenkins. Now, because this plugin still have couple of bugs I would like to point you for now to my own build of this plugin with fixes already in that can be obtained from here. I will take my own version down the moment that all fixes will be merged to the official plugin...
Then let's start with the name. As suggested previously the best way to do so is to use the Build Name Setter plugin. In order to use both plugins to set up a name for your build navigate to the configuration of the project and find an option named "Determine Semantic Version for project" in there, activate it and either use the default name of the variable or provide your own. When you're down scroll down a little bit to the option named "Set Build Name" and activate it. By default you will see the regular build naming convention there - #${BUILD_NUMBER}. You can use that variable as well as any other provided by any plugin, but in this specific case you need to use the environment variable that you have named above, i.e.:
#${BUILD_NUMBER} - ${ENV,var="SEMANTIC_VERSION"}
This will set the name of every build to something more meaningful, so in this case it may result in #76 - 0.0.76-SNAPSHOT. Obviously you're free to experiment on your own to tailor the name of the build to specific format you desire. Keep in mind that it might break your page flow a little bit since the name will be longer than usually, therefore it will push that table with latest builds on the left side of the screen as well it will affect your dashboard.
Now, in order to customize your build information further you might want to take a look at Description Setter Plugin as well. Personally, since I have started to investigate this case further, I use the combination of both at this time. You can use the same token expansion as the one listed above, the big difference is that you will need to create/maintain a file that will be used to create the description. What you will include in this description is only limited by all the variables or token published by Jenkins itself or any of the installed plugins (take a look here). Personally I am listing some information gathered from different places as well as some additional stuff created/provided by Maven during the build process. So it's pretty handy.
Both plugins mentioned above (Build Name Setter and Description Setter) can use other sources of information to build the name and description - it can be properties files, etc. For example one can use Job Exporter Plugin to drop a properties files to read all possible information about the build itself in the form of, as example:
${PROPFILE,file="hudsonBuild.properties",property="build.user.name"}
In this case this will resolve to user name of the user who have triggered the build.
Again, any variable visible to Token Macro plugin can be used.