Jenkins freestyle abort command or steps - jenkins

Does anyone know a command or steps to abort a Jenkins Freestyle job?
I can use a timeout after 3 minutes but I don't see anyway to instantly exit like Pipeline jobs can by setting currentBuild.result = 'ABORTED'.
I'm running Jenkins on Windows so looking for a bat command or similar solution.

You can add "kill" to the end of the path of any running job's execution,
Ex: https://hostname/jenkins/job/DDNS/4902/kill
and it will take you to a page that says:
This URL requires POST
The URL you're trying to access requires that requests be sent using POST (like a form submission). The button below allows you to retry accessing this URL using POST. URL being accessed:
https://hostname/jenkins/job/DDNS/4902/kill
If you were sent here from an untrusted source, please proceed with caution.
There will be a button for "Retry Using POST" -- click that and it will automatically kill any running job, aborting at current stage.
Therefore, if you want to make a script, use that URL with some logic to land on the right job number, with a POST method, and it should do what you want.

Related

Jenkins job submission via curl and get its build number

How to submit the Jenkins job using curl api and get its buid number ?
Note - i tried with the following api, but its not printing any build number.
curl -X POST http://<hostname>:8080/job/<jobname>/build
In general, you can't do this: when you submit (or "trigger") a Jenkins job, this will not necessarily create and start a new build.
When triggering a job, only a request for starting a new build will enter the build queue. Depending on the availability of suitable executors, the actual build will be created (and started) immediately, later, or never at all. Also, multiple queued requests will normally be "squashed", so several submits will result in the same build number.
Bottom line: this can be done (with the constraints mentioned before), but it will require additional (Groovy) scripting for tracking the submit request through the build queue until the build will be started by Jenkins.

Jenkins pipeline: How to prompt "Do you really want to build?"

We are using Jenkins with Pipeline Jobs and of course the awesome Jenkinsfile.
Twice now a developer accidentally clicked on the build button, which ended up causing a bit of chaos. I am trying to figure out if it is possible to have something like a popup that asks "Do you really want to start this build?".
Any ideas on this user related issue are welcome.
Have a look at the article Controlling the Flow with Stage, Lock, and Milestone in the Jenkins blog, which covers a bit more than only asking for confirmation.
Essentially, there is the input step, which requires user input to continue pipeline execution.
The problem with the input step as suggested by StephenKing is that you won't be able to run the build automatically anymore as it will always ask for the user to confirm the input step manually. This prevents "automatic builds" triggered e.g. by webhooks or CRON jobs.
One workaround is to have a timeout and the build is triggered if the timeout is over. Like that, a user can at least abort an unintended build. But this leads to significantly longer build times.
What we did in my old company was, that we created a so called "parametrized" build, which had a simple checkbox "Do you really want to build this job" that resulted in a flag REALLY_BUILD as an environment variable. You can then ask for ${REALLY_BUILD}==1 in the Jenkinsfile. Every time a developer triggers a build, he has to check the box, otherwise the build will not start / immediately stop.
When you trigger your job via a webhook, you can pass a parameter REALLY_BUILD as an URL parameter (see this comment in the Jenkins tracker) and access it in the Jenkinsfile as before.
Here is another resource for how to use parameters in Pipelines.

Use Jenkins REST API to rebuild a build

I have a build in Jenkins which has failed for a temporary reason. I'd like to just re-build it. On the website I just click "rebuild" (from the rebuild plug-in), and if it is a parameterized job, I get asked if I want to keep the parameters. Importantly, the new job contains a "rebuild" link back to the original job enabling back-tracing.
How can I effect this "rebuild" from the REST API. I have code that will get a completed job, extract the parameters, and invoke a new job with those same parameters - so I've got most of the way there.
But I don't know how to establish the rebuild link so I can trace what job is a rebuild of what other job.
You can't -- the rebuild plugin does not implement a REST API (as of current version 1.25; I just checked the sources).
If your job has no parameters, then just GETing the <buildUrl>/rebuild URL should trigger a rebuild, though.
If your job does have parameters, then some more scripting will be needed to mimick what you do manually in those two steps.

Jenkins job wait for first successful build of other job

I have a Jenkins job that should not start building until another job has been built successfully at least once. They are not related per se, so I don't want to use triggers. Is there a way to do this?
Some background: I'm using SCM polling to trigger the second job. I've looked at the Files Found Trigger plugin, but that would keep on triggering the second job after the first on has been built. I've also found the Run Condition Plugin, but that seems to work only on build steps, not on the entire build.
Update - The second job copies artifacts from the first job. As long as the first job has never completed successfully, the Copy Artifact step fails. I am trying to prevent that failure, by not even attempting to build the second job until the first job has completed once.
One solution is to use the Build Flow plugin.
You can create a new flow job and use this DSL:
I've used 10 in the retry section but you can use any numbers.
This flow job can be triggered by monitoring the same SCM URL of your second job.
Update, here is a second solution.
You can use the HTTP Request plugin.
If you want to test that your first job has been built successfully at least once, you can test this URL:
http://your.jenkins.instance/job/your.job/lastSuccessfulBuild/
One example:
As my build has never been successful, the lastSuccessfulBuild URL doesn't exist. The HTTP Request changes my build status to failure.
Does it help?
The Block queued job plugin can be used for this: https://wiki.jenkins-ci.org/display/JENKINS/Block+queued+job+plugin

Provide userName and shortDescription in Jenkins remote API job triggering

I know how to provide build parameters:
wget --post-data='json={"parameter": {"name": "testparam", "value": "HELLO"}}' http://jenkins/job/Job1/build?delay=0sec
But, is it possible to provide a shortDescription and userName in a Jenkins remote API build request via wget/curl?
How should it look like in json or xml? Is there any manual/guidance on the net?
I will use this in along with the problem described in Trigger dynamic set of jobs. I want to provide triggered job with the calling job name and build number.
You may consider using Jenkins CLI (http://[jenkins-host]/cli for help in the browser). You can specify a user to a build CLI command. I'm not sure what you mean by short description when starting a build, though.
Update: Please see Jenkins Wiki Authenticating Scripted Clients. I've created a user foobar ('full name' Foo Bar) and tried the following:
wget --auth-no-challenge --http-user=foobar --http-password=[apiToken] http://jenkins.yourcompany.com/job/your_job/build
Where the token is obtained from user configuration page: http://localhost:8081/user/foobar/configure. It worked. The user has to exist, though. Also, you must specify --auth-no-challenge option, otherwise it kicks off the build as anonymous. The status description says Started by user Foo Bar.
Another Update If everything else fails, you may consider the following workaround: start all builds via the Parameterized Trigger Plugin with an additional boolean parameter that tells the triggered job whether to run or not. In case the job is asked not to run it would fail immediately and call a 'clean-up' job passing to it the build info; the clean-up job then will delete the build from the system.

Resources