On our Jenkins (1.492) I have the Claim Plugin installed. Jenkins is configured to use LDAP using matrix authorization.
After installing the plugin and enabling the plugin in the configuration of each job the /claim view says "Welcome to the Hudson Claim Report. There are no failing builds. Excellent work!" and does not list any builds to claim.
I have both unstable and failed builds.
I have rebuilt the failing and unstable builds after installing the plugin and configuring the jobs.
I have also changed the default view back to "All" - I read somewhere that there may be a problem.
I did also restart Jenkins.
I am logged in with an LDAP user.
The claim view does not list anything.
I have no claim icon in the build history of the job.
I have no claim link on the build page beneathe "started by user".
I have added a "Claim" column to a custom view with failing tests - but it's empty.
But I can claim a single regression via the test report view on a unstable build.
What have I missed? How can I find the problem?
In order to activate the Claim Plugin you must first add the 'Allow broken build claiming' action to the 'Post-build Action' section of one or more jobs. The next time the job fails after adding this step, it should be available to claim.
Configuring this on a large number of jobs is a bit of a pain but fortunately someone has contributed a Groovy script to allow broken build claiming on every job.
Related
I have Jenkins CI/CD dry run job that each developer can trigger. The question is, can each developer have permissions to stop/abort only his flows which he triggered or Jenkins doesn't support it?
The lowest level of authorization is project-based security via the Matrix Authorization Strategy plugin with Job: Build/Cancel and Run: Delete/Replay/Update.
You could use the build user vars plugin together with the Build Name and Description Setter plugin to add the ${BUILD_USER} to the build's name and/or description (with ☑️ Set build name before build starts) so that each dev knows which build to abort in case.
See also How to get the BUILD_USER in Jenkins when job triggered by timer?.
To restrict the build history to the currently logged on user set the build name to #$BUILD_NUMBER - Started by $BUILD_USER and see my user script Jenkins - Restrict build history to current user:
I’m using Jenkins v 1.61 with Java 7. I have a Maven job set up, using SVN for Source Code Management. I have a “Run buildstep before SCM runs” set up (courtesy of the pre-scm-buildstep plugin) and a pre-build step (a short script) set up prior to the Maven goals being run.
My question is, if any of these steps fails, how can I get notified via email of the failure?
Use Jenkins Mailer Plugin, This plugin allows you to configure email notifications for build results.
Plugin ID mailer
Latest Release 1.18
Latest Release Date Sep 04, 2016
Required Core 1.625.3
E-Mail notifications are configured in jobs by adding an E-mail notification Post-build Action. If configured, Jenkins will send out an e-mail to the specified recipients when a certain important event occurs:
Every failed build triggers a new e-mail.
A successful build after a failed (or unstable) build triggers a new
e-mail, indicating that a crisis is over.
An unstable build after a successful build triggers a new e-mail,
indicating that there's a regression.
Unless configured, every unstable build triggers a new e-mail,
indicating that regression is still there.
How about combining pre-scm-buildstep, conditional-buildstep and any-buildstep plugin.
This should allow you to run a publisher step like sending email notifications on a regular build step or a pre scm build step (feature provided by any-buildstep plugin). You could also add a condition check (feature provided by the conditional-buildstep plugin) on the pre-scm-buildstep phase.
You've mentioned that you use a short script prior to the pre-scm-buildstep, just in case you're exporting environment variables as input for your conditional check, remember that you'll also need to write that to a properties file (SEND_EMAIL=true >> my-job.properties) and use env inject plugin to load them on your job environment variables, freestyle jobs don't persist exported shell variables on build steps to be visible to the next steps that come after it.
Lot's of plugins right? Quite annoying. If you want something more elegant, I would recommend using pipeline as code plugin and wrapping everything on a try/catch/finally block, so you could raise an exception before the code checkout stage given a failed check, there are some examples in this article.
Is there any way in jenkins where as soon as we detect the failed build, job revert back the perforce code to the last successful build changelist and fire a build again.
Flow -
1. so as soon as we have failed build - Notifcation will be sent out to dev team with possible checkins which causing the build failure
Revert back the recent code to the last working code and submit it
Initiate a build.
It is possible, but I don't see any reasons or use case to do it as it is not a correct workflow and can be confusing.
But if you decided to do it, the next steps are required:
Example how to do it using Perforce source control.
Steps inside job settings:
Before build triggers you need to save latest changelist number $P4_CHANGELIST - 1
Perforce plugin for Jenkins: Perforce plugin for Jenkins
Build
Get last error code
Get last error code from the: batch
If code != 0 then checkout and build changelsit $P4_CHANGELIST - 1
Jenkins is not a production server. It runs tasks and do not have options that I know for that purpose.
What is your source code ? webapps ? others ?
What steps are you performing ?
Are you performing some automatic tests ?
My assumption is that you got some tests that may invalidate the build.
These tests should be runned :
* on a mock server to prevent deploying on your server
* or somewhere else
Like that, if build failed, nothing is deployed.
If build success, you can deploy your project normally.
If this not reply to your answer, please provide requested information to undestrand a bit more your job process.
If your using an artifact repository like Nexus or Artifactory to manage your project artifacts then you could always redeploy the previous working version of your application when a failure is detected.
Your not cancelling any checked in code that potentially broke the build but you are preserving your test environment. You can configure Jenkins to notify the user who checked in the latest erroneous change set and they can work on resolving the issue.
Jenkins also provides a rich API which allows you to delete a job, start a job, get information about previously run jobs. You could leverage some of these services along with your artifact repo to achieve the experience you described.
There are two machines with Jenkins: one for building, second for testing. If some job is successful on 1st machine, it triggers testing job on 2nd machine via http request. For example:
http://<2nd_jenkins_ip>:8080/job/<job_name>/buildWithParameters?BUILD_NUMBER=167
The problem: It seems that there is something, which launches some of the testing jobs automatically, but it shouldn't. I have deactivated nightly builds, but it happened again. And I can't find out the reason.
Question: Is there any possibility to display the IP/url of the machine, which started the build (e.g. into console output)? If not, can I find this information elsewhere (e.g. jenkins/linux logs)?
EDIT1:
Console shows:
Started by user anonymous
Building on master in workspace <my_workspace>
Cleaning local Directory ./test_data
Checking out ...
Following svn checkout and other build steps.
In the Jenkins_HOME directory on the server, look under jobs/<jobname>/builds/<select the last build you want by date>
In there, open log file (no extension) with any text editor. It will usually provide a more detailed cause at the top of the file.
There are many ways you can prevent unwanted builds. One way is to configure Authentication Token under Job's configuration -> Build Triggers -> Trigger builds remotely. Once a token a set, other (rogue/old) scripts could not trigger the job without providing this token.
This however does not prevent manual triggering through the UI or other projects triggering through Jenkins' methods (not URL).
I've also had some inconsistent issues regarding jobs that were configured on a schedule/timer to the effect that changes wouldn't take effect until Jenkins restart.
Let's say I have this situation. I have three jobs. Job number one has two manually triggered downstream jobs (deploy to test, deploy to prod for example). Something like this:
I want the deployment jobs (test-job-2, test-job-3) to require a password before they are triggered. How can I solve this with Jenkins?
The only option right now supported by the Build Pipeline Plugin is to have a manually deployed downstream job. But this job starts right after you click on it. I would like to require the user to manually enter some parameters (password for example).
Is there some workaround? I was thinking of using the Promoted Builds Plugin. So the deployment jobs would run in a "dry run mode" - just checking that we have ssh access to the server and some other basic stuff. And then in order to deploy you will have to promote the build.
This approach isn't very nice though. Build pipeline and promoted builds plugins don't interact with each other very well.
This is not exactly what you want, but I guess it would some how solve your problem.
View Job Filters
Using this feature in tandem with a security feature such as the Standard matrix based security can help you create a view that will show different jobs depending on who is logged in.
I use different Jenkins Servers to "complete the pipeline" using Build Publisher job to publish the last part of the pipeline job to the other jenkins. I then pick it up from there. Operations teams have access to the "prod" jenkins system, and developers have access to the "dev" system.