I have Jenkins (v2.163) installed and I'm using the plugins email-ext as well as the token macro plugin.
The documentation page of the token macro plugin (https://wiki.jenkins.io/display/JENKINS/Token+Macro+Plugin) tells me that a couple of plugins (that I'm using) like PMD, Warnings, Checkstyle, etc. produce tokens which are also listed on the project configuration page when I click on "Content Token Reference".
Some of the tokens I like to use are CHECKSTYLE_COUNT or PMD_COUNT.
My mail-content for the email-notification looks like this:
Branch: ${GIT_BRANCH}
$DEFAULT_CONTENT
Checkstyle issues: ${CHECKSTYLE_COUNT} (${CHECKSTYLE_NEW} new, ${CHECKSTYLE_FIXED} fixed)
Duplicate code issues: ${DRY_COUNT} (${DRY_NEW} new, ${DRY_FIXED} fixed)
Mess Detector issues: ${PMD_COUNT} (${PMD_NEW} new, ${PMD_FIXED} fixed)
Failed tests:
${FAILED_TESTS}
But all token that are supposed to be filled be the corresponding plugins stay empty (while others are filled), so the resulting mail looks like this:
Branch: origin/stage
PROJECT - Build # 1 - Successful:
Check console output at http(...) to view the results.
Checkstyle issues: ( new, fixed)
Duplicate code issues: ( new, fixed)
Mess Detector issues: ( new, fixed)
Failed tests:
No tests ran.
Am I missing a specific configuration for the tokens to be set?
Related
Failing tests resulted in green balls in our "Open Blue Ocean" pipeline overview. When I read the manual (https://doc.froglogic.com/squish/latest/rg-cmdline.html) this is according to specification, but using the --exitCodeOnFail should result in our desired behavior. In our Jenkinsfile we scripted the following:
squish([extraOptions: """--tags
${tag}
--retry
2
--config
addAppPath
${squishsrcdir}
--config
addAUT
startSimProApp.bat
${squishsrcdir}
--exitCodeOnFail
-666
--config
setResponseTimeout
30""", squishPackageName: 'squish for qt 6.5.2', testSuite: "${squishsrcdir}", unstableBuildOnError: true])
Unfortunately this results in the following error:
com.froglogic.squish.SquishException: unknown option --exitCodeOnFail
The squish plug-in version is: 8.1.1
What are my options to get red balls when a test fails under squish?
The --exitCodeOnFail option is not supported by the Squish plugin.
Take a look at https://doc.froglogic.com/squish/latest/ao-hudson.html#ao-jenkins-example-pipeline-jobs
The squish step sets neither build nor stage result. It returns the execution results as a string instead. Your pipeline may act based on the returned value. You can find an example on the last screenshot in the linked above chapter.
Squish has a known issue (reported and expected to be solved) in matching returned Squish test suite execution status with retries with the final result of the job. For example, if your test fails during first retry and get passed in the next retry, the final status of the job will remain as unstable/failed.
I want to list all available plugins names and their short names using command line option, so that I could automate required plugin installation through jenkins command line.
Kindly advise. Thanks
So far I tried to find answer on same however I got answer only for how to list installed plugins, not for all available plugins.
I've found this link http://updates.jenkins-ci.org/download/plugins/ which lists all plugins but with their short names only
You were so close! The LAYOUT is detailed here. The information is nearby for you to parse, hopefully I got it right.
http://updates.jenkins-ci.org/download/plugins/ is indeed the location of the plugins, with the actual plugin versions sitting inside each folder.
https://updates.jenkins.io/ is the root level. You will find the list of all plugins and details at plugin-versions.json.
update-center.js, update-center.json, and update-center.json.html contain actual update center metadata in JSON, JSONP, and HTML format respectively. You can parse the json to pull everything you are looking for. There are also lists for the documentation url and the release history, as well as the updates.
This is where it's nuanced; there's stable (ie:LTS) or latest (ie:weekly) and major releases of each. Each one has its own sublist, depending on minimum version and compatibility.
Plugin Selection
Since none of this tells you what the plugins actually do, the best thing is to choose your plugins at https://plugins.jenkins.io/. Clicking on any plugin (eg: mailer) reveals a header block with details:
Mailer 1.23
Minimum Jenkins requirement: 1.642.3
ID: mailer
The ID is the short name you are looking for. Go through and find the plugins you want to use and that's your list. Don't worry about the dependencies.
About Plugin Management
Even on a standalone instance, I use a modified script of Docker install_plugins.sh to generate the full list of plugins to install .
Update 2021: As part of GSOC 2019 and refined in GSOC 2020, a new and quite functional Plugin Installation Manager CLI Tool has been introduced to replace all non-GUI plugin mgmt tools, including inatall_plugins.sh. Achieves similar results.
You can examine the outputs or use the groovy script that follows to simplify your "must have" list. Also, as dependency updates happen all the time, I also generate a list of actual installed updates if I need to reapply identically to a different instance rather than from my curated list. My curated list is ~45 plugins, with over 115 getting installed.
eg: workflow-api includes [workflow-scm-step] which includes [git, subversion], so no need to specify git. But you want to know which version you got. Occasionally you may need to explicitly add a dependency to get the latest to avoid a defect, per JENKINS-54018, plugins which were split from Jenkins.
println "Jenkins Instance : " + Jenkins.getInstance().getComputer('').getHostName() + " - " + Jenkins.getInstance().getRootUrl()
println "Installed Plugins: "
println "=================="
Jenkins.instance.pluginManager.plugins.sort(false) { a, b -> a.getShortName().toLowerCase() <=> b.getShortName().toLowerCase()}.each { plugin ->
println "${plugin.getShortName()}:${plugin.getVersion()} | ${plugin.getDisplayName()} "
}
println""
println "Plugins Dependency tree (...: dependencies; +++: dependants) :"
println "======================="
Jenkins.instance.pluginManager.plugins.sort(false) { a, b -> a.getShortName().toLowerCase() <=> b.getShortName().toLowerCase()}.each { plugin ->
println "${plugin.getShortName()}:${plugin.getVersion()} | ${plugin.getDisplayName()} "
println "+++ ${plugin.getDependants()}"
println "... ${plugin.getDependencies()}"
println ''
}
return
I have setup Jenkins to run pylint on all python source files and all the log files are generated (apparently correctly) into a sub-directory as follows:
Source\pylint_logs\pylint1.log, pylint2.log, ..., pylint75.log
I have included a --msg-template definition based on the instructions on my Jenkins Configure page: Post-build Actions->Record compiler warnings and static analysis results->Static Analysis Tools. The template is shown as:
msg-template={path}:{line}: [{msg_id}, {obj}] {msg} ({symbol})
An example of one of the log files being generated by Jenkins/pylint is as follows:
************* Module FigureView
myapp\Views\FigureView.py:1: [C0103, ] Module name "FigureView" doesn't conform to snake_case naming style (invalid-name)
myapp\Views\FigureView.py:30: [C0103, FigureView.__init__] Attribute name "ax" doesn't conform to snake_case naming style (invalid-name)
------------------------------------------------------------------
Your code has been rated at 8.57/10 (previous run: 8.57/10, +0.00)
For the PyLint Report File Pattern, I have: Source/pylint_logs/pylint*.log
It appears that PyLint Warnings is parsing the files because the console output looks like this:
[PyLint] Searching for all files in 'D:\Jenkins\workspace\PROJECT' that match the pattern 'Source/pylint_logs/pylint*.log'
[PyLint] -> found 75 files
[PyLint] Successfully parsed file D:\Jenkins\workspace\PROJECT\Source\pylint_logs\pylint1.log
[PyLint] -> found 0 issues (skipped 0 duplicates)
[PyLint] Successfully parsed file D:\Jenkins\workspace\PROJECT\Source\pylint_logs\pylint10.log
[PyLint] -> found 0 issues (skipped 0 duplicates)
This repeats for all 75 files, even though there are plenty of issues in the log files.
What is odd, is that when I was first prototyping the use of Jenkins on this project, I set it up to just run pylint on a single file. I ran across another StackOverflow post that showed a msg-template that allowed me to get it working (unable to get pylint output to populate the violations graph). I even got the graph to show up for the PyLint Warnings Trend. I used the following definition per the post:
msg-template={path}:{line}: [{msg_id}({symbol}), {obj}] {msg}
Note that this format is slightly different from the one recommended by my Jenkins page (shown earlier). Even though this worked for a single file, neither template now seems to work for multiple files, or else there is something other than the template causing the problem. My graph has flat-lined, and I always get 0 issues reported.
I have had trouble finding useful documentation on the Jenkins PyLint Warnings tool. Does anyone have any ideas or pointers to documentation I can research further? Thanks much!
Ensure pass output-format parameter in pylint command. Example:
pylint --exit-zero --output-format=parseable module1 module2 > pylint.report
you have to set the Pylint's option --message-template in .pylintrc as
msg-template={path}: {line}: [{msg_id} ({symbol}), {obj}] {msg}
output-format=text
I am developing declarative pipeline and want to use file parameter to read its content, but its not working as expected
parameters{
file(fileLocation:'list.txt', description:'contains list of projects to be build')
}
I am getting following error
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 12: Invalid parameter "fileLocation", did you mean "description"? # line 12, column 14.
file(fileLocation:'release-list.txt', description:'contains list of projects to be build')
Following is another option mentioned for basic step plugin
readFile: Read file from workspace
Reads a file from a relative path (with root in current directory, usually workspace) and returns its content as a plain string.
file
Relative ( /-separated) path to file within a workspace to read.
Type: String
encoding (optional)
Type: String
its working in script step like
def myfile = readFile('list.txt')
echo "${myfile}"
But how to use it directly in declarative script as we used other basic steps like dir??
The correct arguments for the file parameter are name and description. So it should be:
file(name:'list.txt', description:'contains list of projects to be build')
However there's an open jenkins issue dating back from 2015 about the file parameter not working for pipelines, so I don't think even this will solve your issue. https://issues.jenkins-ci.org/browse/JENKINS-27413
Following syntax is working
parameters{
file name:'list.txt', description:'contains list of projects to be build'
}
But fileLocation parameter is not acceptable still.
Below syntax is available in Jenkins2 Up & Running book but its not working
parameters{
file(fileLocation:'list.txt', description:'contains list of projects to be build')
}
Till outstanding issues gets fixed, I believe we may have to stick to freestyle mode & handle things either in downstream pipeline job or within same job leveraging needy plugin feature.
Here is my attempt which looks to work file irrespective (yes supports Binaries as well) types : https://i.stack.imgur.com/vH7mQ.png
${list.txt} will point to right file in your case..
Take a look at the plug-in https://plugins.jenkins.io/file-parameters/.
This plug-in adds support for file parameters in your Jenkinsfile: https://plugins.jenkins.io/file-parameters/#plugin-content-usage-in-declarative-pipeline
parameters {
base64File 'small'
stashedFile 'large'
}
https://github.com/jenkinsci/file-parameters-plugin
We were building our solution without any "Pipeline" in Jenkins until recently, so I'm currently in the progress to move our build to multibranch pipelines.
The issue that I'm running into is that we have a lot of structure une our solution(lot of subfolder, and sometimes some big names).
Currently, the jenkins pipeline extract everything in a folder that looks like:
D:\ws\ght-build_feature_pipelines-TMQ33LB5OQIQ5VXVMFKFDG2HWCD4MUOGEGUWJUOMZ5D2GI42BIQA
Which is very-long, and now we are reaching the 260 characters limit of MSBuild:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2991,5):
error MSB3553: Resource file
"obj\Release\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv.dddddddddd.Resources.resources"
has an invalid name. The item metadata "%(FullPath)" cannot be applied
to the path
"obj\Release\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv.dddddddddd.Resources.resources".
The specified path, file name, or both are too long. The fully
qualified file name must be less than 260 characters, and the
directory name must be less than 248 characters.
[D:\ws\ght-build_feature_pipelines-TMQ33LB5OQIQ5VXVMFKFDG2HWCD4MUOGEGUWJUOMZ5D2GI42BIQA\Src\bbbbbb\dddddd\dddddddddddddd\yyyyyyy\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv\xx.aaaaaaaaaa.yyy.bbbbbb.dddddddddddddd.yyyyyyy.vvv.csproj]
We have so much cases where the length is big that it's really a big job to refactor everything, so I'm looking on how to specify to jenkins a smaller path?
What I finally did:
pipeline {
agent {
node{
label 'windows-node'
customWorkspace "D:\\ws\\${env.BRANCH_NAME}"
}
}
options{
skipDefaultCheckout()
}
...
}
And I've a step that does the checkout. It was easier for me to have a "per-job" behavior, without touching jenkins global settings.
Update (for any recent Jenkins instances)
Turns out that with recent Jenkins versions PATH_MAX seems to be ignored.
The only thing it does: Issue a warning in the Jenkins log when smaller than a certain value, which actually does not matter - as the setting itself will anyways be ignored (as seen on Jenkins 2.249.3). See also: JENKINS-2111
As far as I can tell - the new setting was introduced in jenkins-branch-api 2.0.21:
There's a new property introduced: MAX_LENGTH.
This defaults to 32 characters by default.
You can set it the same way like PATH_MAX:
As a java property - to ensure that Jenkins will start using the right setting, e.g.:
-Djenkins.branch.WorkspaceLocatorImpl.MAX_LENGTH=40
or during run-time, using the script console:
jenkins.branch.WorkspaceLocatorImpl.MAX_LENGTH=40
For older Jenkins instances
Actually there's a java property you can set to specify the length of the directory name, e.g.:
-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=20
To make it permanent you have to specify this property in the Jenkins java startup configuration file.
You may also read and write this property using the Jenkins script console for temporary changes or to just give it a try as it takes effect immediately, e.g.
println jenkins.branch.WorkspaceLocatorImpl.PATH_MAX
jenkins.branch.WorkspaceLocatorImpl.PATH_MAX = 20
println jenkins.branch.WorkspaceLocatorImpl.PATH_MAX
Setting this value to 0 changes the path generation behavior.
For details please check:
https://issues.jenkins-ci.org/browse/JENKINS-34564
https://issues.jenkins-ci.org/browse/JENKINS-38706