Jenkins abort downstream job when web button is clicked - jenkins

As a Jenkins beginner, I am seeking the best way to abort downstream Jenkins job when a user hits Submit button on web. The job could either be in a queue or running when user hits 'Stop'.
While searching for possible options, I saw that Jenkins supports REST APIs as well as one can use curl but for that one needs to know the state of downstream job whether it's queued/running.
(Jenkins would need authentication as access is restricted, not sure how tokens work too)

This is still a pending request: JENKINS-11257
jenkinsci/parameterized-trigger-plugin Pull-Request 104 could be a solution if you can modify and rebuilt your own Jenkins Parameterized Trigger Plugin
This python script could help
you can try and experiment with Jenkins: how to stop downstream projects when upstream is aborted and its "kill" nuclear option.

Related

How to trigger a Jenkins Job from outside and receive the status of build

I need to trigger a Job from another Scheduler and want to receive the status of the triggered Job after it finishes.
Sure it would be possible to create a status file or such, but it would be convenient to trigger the Job from a script or per httpRequest and wait for some kind of exit or return code.
Is that possible?
For this, you have to use Build Authorization Token Root Jenkins plugin
It will allow you to run Jenkins build remotely.
Check this image
Please check my article : https://medium.com/appgambit/trigger-jenkins-job-from-slack-5b07b6131e25
But yes you can skip slack integration and just use API for triggering particular job.
Or if you want to run your job after another job is complete or success you have to use "Build after other projects are built"
Build after other projects are built

gerrit-trigger is not triggering jenkins job based on the comment posted to patchset

Jenkins Version: 2.73.1
Gerrit-Trigger plug-in version: 2.27.1
Gerrit Version: 2.14.2
my scenario here is:
New patch set triggers job 1, job1 posts a message (build first) to that patch set, then job2 should be triggered by that comment, but job2 is not triggered for some reason. Below is the configuration of job 1 and job 2
Job 1 Configuration in Gerrit events:
Job 2 Configuration in Gerrit Trigger >> Trigger on
After job 1 executed successfully, this should send a custom message (build first) to patch set and job 2 should trigger based on the message.
Job 2 is not triggering in this case. Don't know what wrong here.
This is not a complete solution as I believe there may be another way to reproduce the issue but we discovered that we can reproduce this issue if we enable the 3 checkboxes:
Build Current Patches Only
Abort new patch sets
Abort manual patch sets
By disabling these settings Jenkins will no longer abort old job builds if a newer patch is available but it will allow Gerrit Trigger to respond to it's own Gerrit Comments thus triggering additional builds.
We have another system we deployed that experiences this issue but even disabling those 3 checkboxes did not resolve it for that system. I feel like certain settings configurations may cause Gerrit Trigger to ignore it's own comments thus not allowing you to create a job that triggers another job by modifying the success/fail messages of the first job.
I ran into this issue recently with Jenkins 2.235.1 talking to gerrit 2.16.9
I found an option in Jenkins
Jenkins->Manage Jenkins->Gerrit Trigger
Edit Gerrit Instance
Click Advanced
Ensure "Trigger on all comments, even default users" is enabled
Not sure if this was added to address the issue documented here or not but it fixed my issue after enabling this and rebooting jenkins.

Can I call a Jenkins job from Udeploy?

I have a different kind of requirement wherein I want a Jenkins job to trigger automatically once an artifact is deployed to udeploy. I know this is reverse of what is usually done (Jenkins job calling udeploy).
I wanted to know if there is any way to do so?
We use CURL and trigger the Jenkins job, in the component configuration there is an option to "Run Process after a Version is Created", hope this helps

run a Jenkins job on another Jenkins instance from the Jenkins job

I want to create a Jenkins job that starts other Jenkins jobs. That would be quite easy, because Jenkins Template Project Plugin allows us to create a build step of a type "use builders from another project". However, what makes my situation harder is that I have to start Jenkins jobs on other machines. Is there any standard way to do that?
In case you want only to trigger new build of Job You Have plenty of ways to accomplish it
you can use remote access API and Trigger a request to build target job from source Job.
https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API
Or you can use https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Remote+Trigger+Plugin
which is handy in handling server details and other stuff. you shoukld ensure ssh keys shared by both servers.

In Jenkins, if next trigger build is in pending state then how to abort running build and start running next pending build?

In Jenkins, If one build is currently running and next one is in pending state then what should i do so that running one should get aborted and next pending one should start running and so on.
I have to do it for few projects and each project has few jobs in it, I tried to save build_number as env variable in one text file (build_number.txt) and take that number to abort previous triggered build but making build_number.txt file for each job is not looking efficient and then I have to create many build_number files for each job for every project.
Can anyone please suggest me some better approach
Thanks
Based on the comments, if sending too many emails is the actual problem, you can use Poll SCM to poll once in 15 minutes or so, or even specify quiet time for a job. This will ensure that build is taken once in 15 minutes. Users should locally test before they commit. But if Jenkins itself is used for verifying the commits I don't see anything wrong in sending an email if build fails. After all, they are supposed to know that, no matter even if they fixed it in a later update intentionally or unintentionally.
But if you still want to abort a running job if there are updates, you can try the following. Lets call the job to be aborted as JOB A
Create another job that listens on updates same as that of the job that needs to be aborted
Add build step to execute groovy script
In the groovy script use Jenkins APIs to check if JOB A is running. If yes, again use APIs to abort the job.
Jenkins APIs are available here

Resources