[JIRA] [parameterized-trigger-plugin] (JENKINS-11257) Stopping a parent job doesn't stop the triggered child jobs

419 views
Skip to first unread message

sschuberth@gmail.com (JIRA)

unread,
Aug 27, 2015, 11:11:14 AM8/27/15
to jenkinsc...@googlegroups.com
Sebastian Schuberth edited a comment on Improvement JENKINS-11257
 
Re: Stopping a parent job doesn't stop the triggered child jobs
Is there any way to work around this, e.g. by using some Groovy scripting [~nickolay] Would you mind sharing your script ?
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

sschuberth@gmail.com (JIRA)

unread,
Aug 27, 2015, 11:11:14 AM8/27/15
to jenkinsc...@googlegroups.com
Sebastian Schuberth edited a comment on Improvement JENKINS-11257
[~ nickolay nickolayr ] Would you mind sharing your script?

nickolay.rumyantsev@emc.com (JIRA)

unread,
Aug 27, 2015, 11:33:01 AM8/27/15
to jenkinsc...@googlegroups.com

Sebastian Schuberth,
I am afraid it's lost now. The problem was that users often clicked the Abort button twice which causes Post build to be aborted too.
However the overall idea was the following:

  • In Groovy Postbuild, or System Groovy script
  • Get all currently running builds like here: Find builds currently running that has been executing for more than N seconds
  • For each build follow getUpstream()->getUpstream()... saving the build chain until you meet your current build, where
    upstream = build.getCause(hudson.model.Cause.UpstreamCause)?.upstreamRun
  • Call doStop() for each build in the resulting chains starting from the earliest build.

sschuberth@gmail.com (JIRA)

unread,
Aug 28, 2015, 8:40:03 AM8/28/15
to jenkinsc...@googlegroups.com

ikedam Do you have a convincing example for a use case where it actually makes sense to continue running the triggered jobs when the parent build has been stopped by the user?

phillip.l.viana@gmail.com (JIRA)

unread,
Oct 5, 2015, 2:00:02 PM10/5/15
to jenkinsc...@googlegroups.com

+1 Nickolay, Sebastian totally vote for this one.

I can't think of a use case where it makes sense to continue running a downstream job after the upstream job is cancelled.

Several – if not most – jobs that I see in Jenkins trigger one or more downstream jobs since they are part of a whole. Not cancelling the downstream job is a severe defect, or counter-intuitive and confusing at best.

In my opinion, if there is such use case pointed out by Sebastian above, there should be an option that allows downstream jobs to keep running after the upstream is cancelled, and this option should be disabled by default.

patrick.poetz@infonova.com (JIRA)

unread,
Oct 13, 2015, 7:54:02 AM10/13/15
to jenkinsc...@googlegroups.com

Totally vote for this.
We would need it for a wrapper job which starts about 100 jobs in parallel.
And if the config is f****d up all subjobs must be aborted manually.

anish.dangi@gmail.com (JIRA)

unread,
May 15, 2016, 2:26:02 AM5/15/16
to jenkinsc...@googlegroups.com

We needed this feature as we trigger and abort jobs from the command line, which makes it easy to abort. The zombie child jobs would tie up our build machines. I added this functionality to the plugin: Here is the relevant commit https://github.com/ad22/parameterized-trigger-plugin/commit/30ec9844e026c4a95eb3663e8c4c9d4a3d74fd01

anish.dangi@gmail.com (JIRA)

unread,
May 15, 2016, 3:19:02 AM5/15/16
to jenkinsc...@googlegroups.com
Anish Dangi updated an issue
 
Jenkins / Improvement JENKINS-11257
Change By: Anish Dangi
Comment:
We needed this feature as we trigger and abort jobs from the command line, which makes it easy to abort. The zombie child jobs would tie up our build machines. I added this functionality to the plugin: Here is the relevant commit https://github.com/ad22/parameterized-trigger-plugin/commit/30ec9844e026c4a95eb3663e8c4c9d4a3d74fd01

anish.dangi@gmail.com (JIRA)

unread,
May 15, 2016, 6:35:02 AM5/15/16
to jenkinsc...@googlegroups.com
 
Re: Stopping a parent job doesn't stop the triggered child jobs

We needed this feature as we trigger and abort jobs from the command line, which makes it easy to abort. The zombie child jobs would tie up our build machines. I added this functionality to the plugin: Here is the relevant commit https://github.com/ad22/parameterized-trigger-plugin/commit/d00a079a580d0b71168c1dd12d5ad8e13c658f94

bitwiseman@gmail.com (JIRA)

unread,
Mar 28, 2018, 4:20:02 PM3/28/18
to jenkinsc...@googlegroups.com
Liam Newman updated an issue
 
Change By: Liam Newman
Assume you have a job A that launch a child Job B and that job A has to wait Job B finished to continue its steps.

If you stopped job A while job B is processing, the job B isn't stopped.
It should be stopped.

 Precondition:
I have a parent job "Parent" that triggers child jobs "Child(1-N)", and then blocks waiting for them to finish.

Action:
1. Start Parent job.
2. Wait for children to launch.
3. Abort Parent job.

Current result: 
Parent job aborts but children continue to run. If the child jobs have no meaning outside of the parent, then child jobs have to be manually aborted.

I can see why you would want this behavior. It is certainly the correct behavior in the "post-build step" case. It is probably correct in the "non-blocking build step" case. In the case of the parent build blocking on children completing, there are definitely scenarios where it is not.

Desired Enhancement:
When "Block on child job completion" checkbox is checked, a list of options is shown. Add option to the list: "Child job action when parent job is aborted". Values: "None, continue running (default)", "Abort immediately".
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

sridgma@gmail.com (JIRA)

unread,
Apr 3, 2018, 1:23:05 PM4/3/18
to jenkinsc...@googlegroups.com
Sridharan Gopalan commented on Improvement JENKINS-11257
 
Re: Stopping a parent job doesn't stop the triggered child jobs

Here is how this works for our need. I explored quite a few options but this probably the best and easy solution that worked for me.

  1. Install the "post build task" Plugin in jenkins.
          https://wiki.jenkins.io/display/JENKINS/Post+build+task.
  2.  Add a post build task in the upstream job and add a Log text as "Build was aborted" (When user cancel the job manually the console log will have this text).
  3.  In the Script section of the task, add a ruby code and read step 4.
  4.  I wrote a ruby script(you can convert and use whatever language binding you want) that actually iterates all the downstream jobs and get the full URL corresponding upstream build.
  5. In the ruby script, i pass the Upstream Job's build number and the credentials of the CI User and Api token has an access to make a POST call to stop the job.
  6. The ruby script will return the full URL(s) of the downstream job(s) and make a POST call to REST Api to stop the job.
  7. I had 3 Downstream jobs, alter the script based on the number of downstream jobs.

P.S: If you ever see 403 returning when stopping the job, probably the credentials you use may not have an adequate permission for the POST call.

Ruby Script
=========

 

/usr/bin/env ruby <<-EORUBY

require 'httparty'
require 'json'

downstream_jobs = ['downstream_job_1', 'downstream_job_2', 'downstream_job_3']
downstream_job_url = []
upstream_build_id = ENV['BUILD_NUMBER']
auth = {username: ENV['CI_USERNAME'], password: ENV['CI_API_KEY']}

downstream_jobs.each do |dsj|
  response = HTTParty.get("https://<jenkins-server>/job/#{dsj}/api/json?depth=1", basic_auth: auth)
  data = JSON.parse(response.body)['builds']

  data.each do |child|
    child ['actions'].each do |c|
      if !c['causes'].nil?
       c['causes'].each do |d|
        if d['_class'].include?('hudson.model.Cause$UpstreamCause') && d["upstreamBuild"].to_s ==    upstream_build_id.to_s
          downstream_job_url.push(child["url"])
          break
         end
       end
     end
   end
 end
end


#Stop all the downstream jobs
#http://<Jenkins_URL>/job/<Job_Name>/<Build_Number>/stop
downstream_job_url.each do |ds_url|
  puts "#{ds_url}stop"
  response = HTTParty.post("#{ds_url}stop", basic_auth: auth)
  puts response.code unless response.nil?
end

EORUBY

hboeken@me.com (JIRA)

unread,
Aug 3, 2018, 8:31:02 AM8/3/18
to jenkinsc...@googlegroups.com

It is so annoying to have to abort all child jobs everytime I abort a parent job. Now I started to search for a solution and ended up with this 7 year old bug report. Why isn't this fixed or at least added as an additional option as requested? Is it too complicated?

I voted for this ticket now and hope to see a solution during my lifetime.

Until then I'm going to try Sridharan Gopalan's workaround.
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

sschuberth@gmail.com (JIRA)

unread,
Aug 9, 2018, 10:50:02 AM8/9/18
to jenkinsc...@googlegroups.com

Why isn't this fixed or at least added as an additional option as requested?

 

The PR to solve this is pending for a long time, see https://github.com/jenkinsci/parameterized-trigger-plugin/pull/104, it just never was merged

bahdad@bigmir.net (JIRA)

unread,
Sep 4, 2018, 6:22:02 AM9/4/18
to jenkinsc...@googlegroups.com

Meanwhile, I can share my adopted python script for aborting downstream builds automatically. Inspired by Sridharan Gopalan

 

jenkins_postbuild_abort_downstream-py
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

ploutarchos.spyridonos@gmail.com (JIRA)

unread,
Apr 9, 2020, 10:28:03 AM4/9/20
to jenkinsc...@googlegroups.com

Is there any update on this? My team would be very interested in this feature request.
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

p.a.chachotkin@gmail.com (JIRA)

unread,
Apr 30, 2020, 3:04:05 AM4/30/20
to jenkinsc...@googlegroups.com

Are there any updates on this problem?
We need that functionality, too.

p.a.chachotkin@gmail.com (JIRA)

unread,
Apr 30, 2020, 3:12:03 AM4/30/20
to jenkinsc...@googlegroups.com
Pavel Chachotkin edited a comment on Improvement JENKINS-11257
Hi [~huybrechts]
This improvement request was opened in 2011. 9 years have gone by since that moment.
30 watchers, 29 votes.
 Are there any updates on this problem? Or blockers for implementation?
We need that functionality, too.
Reply all
Reply to author
Forward
0 new messages