I was wondering if it is possible to change the built-in build statuses that are reported by Jenkins via email (i.e. Still Failing, Failure, etc..)? I was looking into the groovy post build plugin, but I can't seem to get the code to change the build status.
Here is my simple code:
if(manager.logContains(".*xyz.*")) {
manager.buildSuccess()
}
Also, if someone could post where I can learn more about using Jenkins w/groovy to access Jenkins configuration settings, that would be great. I search the web but did not find anything to useful.
Thanks for any help,
Eric
For changing the E-mail messages i would suggest the E-Mail-ext plugin
For changing status, you may like to try the Jenkins Text Finder plugin.
Related
The Save/Apply button is missing from Jenkins pipeline configuration page. There seems to be no other way to apply changes to the configuration settings. I am unable to find any useful answers or workarounds as well. I have tried several Javascript workarounds, reinstallation, uninstalled plugins that generated warnings, and stuff but nothing seems to be working. I am using Jenkins version 2.222.3 with BlueOcean.
It would be a great help if anyone can suggest a solution.
Jenkins Pipeline configuration is defined in Jenkins Pipeline (e.g. Jenkinsfile). To change your configuration, you need to edit your Jenkinsfile.
E.g. to change "Build periodically", here's an example of edit you need to do:
pipeline {
triggers {
cron('* * * * *') // run every minute
This is why the page you're looking at is called "View Configuration" — it is for viewing only.
Using the GitHub plugin, we have an organization folder that is scanned for any repositories that contain a Jenkinsfile. The configuration you are viewing is driven by a config.xml that is copied from the organization folder into each job that runs in a repo. So you want your changes to affect jobs/my_organization/config.xml, not jobs/my_organization/jobs/my_repo/config.xml.
In the UI this is accomplished by going up a level or two from the job or job run. There you will see the link change from "View Configuration" to "Configure".
I am using jenkins to run jobs that uses maven with cucumber . my jobs are running succesfully. I have also managed the plugin Cucumber report in jenkins. But when i view the report i am getting the message as shown in below picture.
I have tried to install various plugins like Jenkins plugin, standalone but with no joy. These are shown as options in the bottom right of the report.
Any clue is helpful. I have tried to check this error in stackover flow also. I didnt get any clue
I could see the reports file in xml which is created by surefire plugin. Any way i can achive reporting part in my project
I managed to get reports in jenkins now.
Previously Jenkins is unable to find the json file in my project.
I have set the path of json file as target and i could able to see the reports.
This might help for those who are looking for answer.
#CucumberOptions(
features= "C:\\Users\\dd pc\\workspace\\PracticeCucumber\\src\\main\\java\\com\\qa\\feature\\Test.feature",
glue= {"com\\qa\\stepDefinition"},
format= {"pretty","html:test-output_1",
"json:target/cucumber-reports/CucumberTestReport.json"},
plugin = ("json:target/cucumber-reports/CucumberTestReport.json"),
monochrome= true,
dryRun= false
)
I am able to solve by providing **/*.json
under Post-build Actions/Cucumber Report/JSON Report Location/ File Include Pattern = **/*.json
First of all in runner file we need to provide following plugin as follows: plugin= {"json:target/cucumber.json" }
Now in Jenkins job, in "post build" section during configuration, add cucumber reports, click on advanced option and provide 'target' text in "JSON Reports Path" text field. Save the job, it will run and will work fine.
Note: target text is the name of folder which we have provided in runner file for generating reports in Json, also cucumber report plugin works on json so need to generate report in json.
I my case the problem was in two jobs over the same test repository (one for Chrome one for Firefox), where one deletes report files after the job while second job was already running and vice versa.
We are using Jenkins in our build cycle to run our specflow tests. We are trying to find a better way to surface the test results. The generated html report file is great, but right now we have to manually log into the build server to check it out. I want to surface that file via a clickable link.
Here is what I am talking about specifically. Here is the test results via our Jenkins console
I want to change the highlighted text to an http url so that everyone can just click that and view the file.
I already have the http link working, so that's not the issue. I just need to figure out how to make specrun output this link here.
Any ideas on if this is possible? And if so how to do it?
Thanks for the help!
Sorry, this is currently not possible in SpecFlow+Runner, but I will put it on the backlog as a feature request.
Perhaps you can do something in Jenkins to parse the output and reformat the link.
Full disclosure: I am on of the developers of the SpecFlow+Runner.
Is there a way to get the hudson job initiated user name.
Is it possible to get using script shell, py etc.
Lets assume I have the build # which was initiated. I know how to get the latest build info using api but would like to get a user details for a specific job.
Do you think, this will work for hudson? :)
https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin
Thanks in advance
That plugin will not work with Hudson, unless you download a very old version of the plugin. I'm not sure how many people are still using Hudson and haven't upgraded to Jenkins.
Anyway, when a user manually triggers a build, this is called a "user cause"; there are other types of cause, e.g. SCM trigger.
You can use the JSON or XML API to get the causes for a build, for example:
https://ci.jenkins-ci.org/job/remoting/lastSuccessfulBuild/api/xml?xpath=//action/cause/userId
In this case, this returns the username that caused the build to run.
Though note that there may be multiple causes for a build, and potentially other cause types that use the userId field.
This works in Jenkins, but it should also work in Hudson, but I haven't tested it.
We have an old install of Hudson (ver. 1.379, yes that old...) that hasn't been upgraded yet (and I am not quite sure when and if it will be by the people responsible for it).
There seems to be some place, apparently unaccessible from the web interface, were additional recipients for the email-ext plugin were added...
Problem is, those recipients no longer exist and quite a few people (mostly unrelated to the people who use Hudson) get spammed by bounces from those emails...
For email-ext I get this in the plugin page:
version: 2.12 installed: 2.8
I have looked at the configs and I believe email-ext config should be under "Editable Email Notification" of that job...
I see some of the recipients of those emails but not the person who left, it looks like this was configured elsewhere, maybe manually in some sort of config file.
Where can I look for this?
Thank you!
Puzzled!
There is global configuration. Go to Manage Hudson, then Configure System (the wording my be different based on your version, but you should end up here http://<hudsonurl>/configure. You need to have global administrative permissions to access this, but based on what you are saying, it sound like you do not.
Based on your version of the plugin, under Extended E-mail Notification, you will see Default Recipients. Older versions of the plugin did not have that feature.
Also, under the job configuration itself, there are several places to override/add to the list of recipients, the most buried of which is under the Triggers
Click Advanced... button under Editable Email Notification
For each trigger, click Expand link.
Lastly, it is possible that people are included on the emails cause they were Culprits. In Hudson's terms, these are people who committed to SCM since the last successful build. If the build has been failing since then for a long time, they are just there as culprits. The only way to "reset" the culprits is to let the job build successfully