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

When I abort a Pipeline I mean for it to be aborted.

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • workflow-job-plugin
    • None

      The attached screenshot is from ci.jenkins.io. I haven't understood this user experience for some time, but today it's especially frustrating.

      I think Pipeline could be improved if instead of showing links which an administrator must click ("It appears you're trying to abort a Pipeline, could I help you with that?") the Pipeline should just abort the Pipeline.

      In the screenshot, I must click three times to accomplish the behavior I originally intended when I aborted the Pipeline in the first place. Instead, the forcible termination of running steps, and t hen forcible killing of the entire Pipeline should happen automatically after some timeout.

          [JENKINS-48048] When I abort a Pipeline I mean for it to be aborted.

          Andrew Bayer added a comment -

          I've thought about this sucker before. There is logic behind the idea of the initial abort just killing the current step, so that other non-failfast parallels would continue, or Declarative post actions can still run, etc. But leaving things dangling forever if killing the single step doesn't work is a bad experience. I'd say we should do something like the following when you click abort:

          • Abort the current step - i.e., the current initial behavior.
          • If that doesn't work in 10 seconds, forcibly terminate the current step - i.e., the behavior that now requires a click 10 seconds after the first click.
          • And if that doesn't work in 10 seconds, kill the whole build to death - i.e., the behavior that now requires a third click 10 seconds after the second click.

          I just don't see any reason for requiring human intervention in those cases.

          Andrew Bayer added a comment - I've thought about this sucker before. There is logic behind the idea of the initial abort just killing the current step, so that other non-failfast parallels would continue, or Declarative post actions can still run, etc. But leaving things dangling forever if killing the single step doesn't work is a bad experience. I'd say we should do something like the following when you click abort: Abort the current step - i.e., the current initial behavior. If that doesn't work in 10 seconds, forcibly terminate the current step - i.e., the behavior that now requires a click 10 seconds after the first click. And if that doesn't work in 10 seconds, kill the whole build to death - i.e., the behavior that now requires a third click 10 seconds after the second click. I just don't see any reason for requiring human intervention in those cases.

          Jesse Glick added a comment -

          Yes but you need to be careful not to get overeager in case the StepExecution.stop was honored and the build is simply proceeding in various post blocks or whatever. So simply giving the build 10s to complete is not correct.

          Something is broken in the screenshot; if DurableTaskStep.Execution has printed the After 10s process did not stop message, it has already sent StepContext.onFailure so it is unclear “where” the execution engine now is. Would need a way to reproduce this behavior so we could diagnose the problem. Is there some enclosing block step which is failing to handle the body failure, or what?

          Jesse Glick added a comment - Yes but you need to be careful not to get overeager in case the StepExecution.stop was honored and the build is simply proceeding in various post blocks or whatever. So simply giving the build 10s to complete is not correct. Something is broken in the screenshot; if DurableTaskStep.Execution  has printed the After 10s process did not stop message, it has already sent StepContext.onFailure so it is unclear “where” the execution engine now is. Would need a way to reproduce this behavior so we could diagnose the problem. Is there some enclosing block step which is failing to handle the body failure, or what?

          Andrew Bayer added a comment -

          jglick - Yeah, by "if that doesn't work", I meant "if the specific step hasn't stopped".

          Andrew Bayer added a comment - jglick - Yeah, by "if that doesn't work", I meant "if the specific step hasn't stopped".

            Unassigned Unassigned
            rtyler R. Tyler Croy
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: