I want to make the build fail by analyzing the results of the console log, for a mac project I am building. It builds each module and gives the results like this:
###################################
XX XXX XXX
##########################
It then returns BUILD FAILED
I want to show that the build failed at the end of the console output, and at the same time I want to know which module failed. It should be sent by email since I am already using the email-ext plugin.
I am unsure of what needs to be done; I am aware of text-finder, log parser and setting the run condition - but do not know what steps to follow.
You will need to use the text-finder plugin and the email-ext plugin together in order to accomplish both your objectives.
First set up the text-finder plugin and provide an appropriate regex. Something like: .*(?i)failed.*|.*(?i)error.* would find the words "failed" or "error" in a case insensitive manner. You will need to specify a path to your log files and probably want to check the "Also search console output" check box.
This will cause any build which outputs "failed" or "error" to fail in Jenkins.
Your requirement to email the module which failed is a little more complex, but possible with the email-ext plugin. This plugin allows you to specify a regex which is used to gather email content using a special token which accepts arguments. The full argument list and token name is: ${BUILD_LOG_REGEX, regex, linesBefore, linesAfter, maxMatches, showTruncatedLines, substText, escapeHtml, matchedLineHtmlStyle}
Most of these arguments are optional, something like this should do the trick for you: ${BUILD_LOG_REGEX, regex=".*(?i)failed.*|.*(?i)error.*", linesBefore=10, linesAfter=10}. Put this in the "Default Content" section of the email-ext configuration. You can specify multiple tokens as well, see this answer for instructions to get the full list: Jenkins Email-ext plugin - tokens
You can of course edit the LinesBefore and LinesAfter parameters to suit your needs.
Related
The Jenkins email-ext plugin supports a ${LOG_REGEX} 'token'. It's documented like this:
${LOG_REGEX}
Uses a regular expression to find a single log entry and generates a new output using the capture groups from it. This is partially based on the description-setter plugin (https://github.com/jenkinsci/description-setter-plugin).
(That's part of the documentation that's shown when I click on the "?" (question mark) associated with the Content Token Reference in the Editable Email Notification section of the Jenkins project configuration page.)
When I use this token, how do I specify the regular expression and the output? I guess it probably takes a pair of parameters, but, if so, what are their names?
I determined through trial and error that the parameter names are regex and replacement.
For example, if your job console contains
Started by upstream project "my-project" build number 12345
then the token
${LOG_REGEX, regex="^Started by upstream project \"(.+)\" build number ([0-9]+)", replacement="\\1 #\\2"}
will be replaced by
my-project #12345
Keep in mind that, in parameter values, \ and " must be escaped with a \.
I've got a parameterized freestyle Jenkins job, and I'd like to include part of one of the parameters in the build name. The parameter that I'm interested in is called FILE_PATH. Due to the file directory structure of the project used by this job, the file path always starts with the same string, which is 9 characters long. So if FILE_PATH="somepath/what/I/want", I would like the name of my build to be what/I/want.
Some things I've tried putting in the "Set Build Name" field provided by the Build Name Setter plugin:
${FILE_PATH:9}
This gave me the following error:
Failed to evaluate name macro:org.jenkinsci.plugins.tokenmacro.MacroEvaluationException: Unrecognized macro 'FILE_PATH' in '${FILE_PATH:9}'
${"FILE_PATH":9}
FILE_PATH was just treated as a string:
New run name is '${"FILE_PATH":9}'
${$FILE_PATH:9}
This just led to the raw expression being included with FILE_PATH being expanded:
New run name is '${somepath/what/I/want:9}'
${ENV,var="FILE_PATH":9}
This didn't get processed at all:
New run name is '${ENV,var="FILE_PATH":9}'
I've got the Build Name Setter and the Token Macro plugins installed. I'd like to do this in the Build Name plugin, if possible, although I can install any other plugins I need to get this to work.
${ENV:9,var="FILE_PATH"} should do what you are looking for.
An alternative is to also eliminate the beginning of the string, as far as you know what exactly the string is:
${ENV#somepath/,var="FILE_PATH"}
In case you ever need to strip something from the end of the string instead, use % in place of #.
I'm assuming you are using a Jenkinsfile pipeline script?
If so, you can just use the groovy substring method.
variable.substring(9)
Not sure if you can do something similar using parameterized builds.
I've configured a service hook in VSTS to connect to Jenkins. I'm able to use the Jenkins extension to trigger a Jenkins job if it's not in a subfolder. E.g. http://myhost/job/Always%20succeed/
In that case, I can simply connect like this and run my job:
If my job is nested, however, I can't figure out how to connect. Here's an example: http://myhost/view/Production/job/Automation/job/Test/job/My%20Job
I've tried using just the name (e.g. "My Job"), the whole url, and a dot notation (Production.Automation.Test.My Job). How can I make this run and where can I find more documentation?
It's pretty nuanced and one could argue buggy. First off, I can reach the same job with two urls:
http://myhost/view/Production/job/Automation/job/Test/job/My%20Job
http://myhost/job/Automation/job/Test/job/My%20Job
Turns out the latter is the way to go.
I tried the following name, and it tried reaching the corresponding endpoint:
Automation/job/Test/job/My%20Job <- name used in VSTS "Job name" field
/job/Automation/job/job/Test/job/My%20Job/build <- url attempted, failed (404)
Note the double job/. Then I tried the following with better results:
Automation/Test/job/My%20Job <- name used
/job/Automation/job/Test/job/My%20Job/build <- url tried, success
It's a bit concerning that the pattern isn't consistent regarding the double "job/" part but whatever.
When I run a manual build, I'd often like to mark it with documentation to show why I ran it. Is this feature available with a plugin?
thank you!
I would approach this by adding a build parameter as a string, as above, then use the Description Setter Plugin to set it from that parameter. We use something like this for the regex:
^\++ : BUILD DESCRIPTION : GERRIT_CHANGE_OWNER_EMAIL=([^#\s]*)\S*, BUILD_USER_EMAIL=([^#\s]*)\S*, GERRIT_BRANCH=(\S*), GIT_COMMIT=(\S{8}).*$
and this for the description:
\1\2, \4, \3
As a result we get:
jspain, 0ee3198b, master
or when it fails, we get:
Failed due to timeout.
wayvad, fc7bdf2a, master
this "Failed..." text comes from the Build Timeout Plugin
I am not aware of a plugin that can do this, and after a brief search I could not find one to do what you describe.
You can mimic this behavior by adding a string parameter in the job that takes a default value of automatically started when it's normally run, but that you can change to my reasons for this build when starting it manually.
You could then use a batch (or groovy or ) build step to print the contents of that parameter into the build log. If you do some sort of SCM checkout I'm not sure how close you can get it to print to the line that contains the username that started the job, however you can click on the view parameters button in the job build and see what was in the field quickly without having to parse the logs.
The downside of this is that parameter would have to be added to each job.
Culprits is the list of users who committed a change since the last non-broken build till now. The Jenkins Email-ext plugin is able to send an email to the culprits during a Post-Build action.
I want to use the list of emails defined by Culprits in a python script build step inside of my Jenkins job.
Can anyone suggest how I can do this?
The 'culprits' list comes from the SCM plugin in jenkins and includes all users who have committed since the last successful build. Ultimately the email-ext plugin is sourcing its list from scm and generating the email addresses based on the following heuristic
The plugin will generate an email address based on the committer's id and an appended "default email suffix" from Jenkins's global configuration page. For instance, if a change was committed by someone with an id "first.last", and the default email suffix is "#somewhere.com", then an email will be sent to "first.last#somewhere.com"
If your email addresses have some sort of pattern (and they must do, otherwise the email-ext plugin would not be generating the correct addresses) then you can generate them yourself inside a groovy script eg:
import hudson.model.*
def culprits = build.getCulprits()
def list = culprits.collect{it.getFullName().toLowerCase().replace(" ", ".") + "#mydomain.com"}
This example would convert a culprit like "Adam Smith" to adam.smith#mydomain.com
But you could replace the call to getFullName() with a call to getId() and manipulate that however appropriate. eg:
def list = culprits.collect{it.getId().toLowerCase() + "#mydomain.com"}
Which is the basic format that email-ext uses - You can get a full list of user properties from the documentation.
Now you have the list in a groovy script, but how to make that list available to your python script? That will come down to what you are used to doing. You could write the list to your workspace and read it from python, or save the result to an environmental variable, or even save it to a build parameter.