I just updated my Jenkins server to 2.32.2 and I noticed in the Release Notes that they added a feature which asks the user for confirmation before aborting a build (this issue: https://issues.jenkins-ci.org/browse/JENKINS-30565)
Is there a way to disable this feature? There are some cases where I have automated job cancellation using scripts and this new behavior would have an effect on all of those scripts.
This change only affects the browser interface. Any cancellation of builds via the Jenkins CLI or SSH interfaces, for example, would not be affected.
Related
My team and I are currently building a project with Travis CI, which initiates a script on remote server. When we click to cancel builds in the Travis UI, the Travis build stops but the script on the remote server continues to run.
Is it possible to automatically run a command after cancelling builds, so that we can tell the remote server to stop executing the script?
Thank you to Travis CI support for this email response:
When a build or job is manually cancelled (or terminated by one of our
workers for a different reason) it is killed without any chance of
cleanup. So no, there is no special after_cancelled hook and
after_failure as well as after_script are not executed when
manually cancelling. This has to do with the way our build lifecycle
is implemented and making an after_cancel possible requires quite
some changes.
We are aware of this issue. It has been raised in our public tracker
https://github.com/travis-ci/travis-ci/issues/4221 and is also being
discussed internally. Unfortunately I cannot give you any time frame
when we will address this issue but we will update the public ticket
once there is progress.
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.
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.
I'm completely stuck with Gerrit Trigger install. I installed Jenkins ver. 1.482 with the Gerrit Trigger (v2.6.0) plugin. I'm not able to configure it.
I installed a test gerrit server (v2.4.2). I have an admin user. I tried to configure Gerrit Trigger to use this access to build patches (this is a test system, I didn't want to bother to add real users).
In Gerrit Trigger options I configured gerrit access. Test connection button says conection is ok. Although I get The connection to Gerrit is not started yet. Check the Gerrit URL in the settings. warning on the top. I also tried to push restart at the bottom.
I've read documentation on both Hudson and Jenkins page of the plugin. I'm still unable to configure the plugin.
Do you have any idea what's wrong?
Probably Click the button to Save after testing, this is common mistake that you forget to save it !! I met this several times
See more explanation in https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
Otherwise it is not clear what's your problem since this is a normal case.