Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53338

Job abort (e.g., induced by ghprb) occasionally doesn't work


    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • multijob-plugin
    • None

      We have noticed that sometimes, an ABORT on a parent job doesn't actually abort the child job.  Re-aborting the child job is usually successful.

      An example log in question might look like this. First, the parent job claims that it aborted the job:

      *00:49:04* Aborting all subjobs.
      00:49:24 Finished Build : #13557 of Job : caffe2-builds/conda2-macos10.13-trigger-build with status : ABORTED

      You go look at the log of the job in question, and what do you know: it's still going:

      Jenkins >> caffe2-builds >> conda2-macos10.13-trigger-build >> #13557
      00:49:2300:49:23  Started by upstream project "Started by ups pytorch-pull-request" build number 18544
      00:49:23 originally caused by:
      00:50:45     >> Job status: [conda2-macos10.13-build] the 'build only if scm changes' feature is disabled.
      00:50:45 Starting build job caffe2-builds/conda2-macos10.13-build.

      Whenever I see this occur, it does seem like the job is wedged on "Starting build job" in the console; actually, when you look at the build summary page, you will see that the build in question is successfully running.

      Anyone seen this before, know what it could be up? We're running Jenkins 2.107.3 and Multijob 1.30. The cancellations are generated automatically by ghprb 1.40.0. We checked the new commits in Multijob 1.31 and they did not seem applicable to our problem. I haven't checked the changelog for newer versions of Jenkins, and am half hoping someone will pipe up saying that this was fixed in such-and-such version of Jenkins.

            Unassigned Unassigned
            ezyang Edward Yang
            0 Vote for this issue
            1 Start watching this issue