How to fail pipeline build, but still return a value

[Christian McHugh]

Greetings,

For the saltstack plugin to support pipeline, it attempts to return the job output. Since it should always return the output, in case of a problem, the build is marked as a failure, but processing still occurs after the salt step.

So given a pipeline where a salt message is sent, followed by other things (such as an echo)

pipeline {

    agent {

        label "agent1"

    }

    stages {

        stage('run salt') {

            steps {

                script {

                    output = salt authtype: 'pam', clientInterface: local(arguments: '"sleep 5; ls -la"', blockbuild: true, function: 'cmd.run', jobPollTime: 6, minionTimeout: 4, target: '*', targettype: 'glob'), credentialsId: 'b5f40401-01b9-4b27-a5e8-8ae94bc90250', servername: 'http://localhost:8000'

                    echo output

                }

            }

        }

        stage('another thing') {

            steps {

                echo "next thing"

            }

        }

    }

}

If salt runs into a problem, I would still like it to return the output string, fail the build, but also stop processing. Currently marks the build as a failure, but since there was no other exception raised, the pipeline tasks continue

...
Some minions returned. Waiting 4 seconds
ERROR: Minions timed out:
["minion1"]


[Pipeline] echo
[{"master":{"return":"total 20\ndrwx------  3 root root 4096 Mar 25 07:51 .\ndrwxr-xr-x 25 root root 4096 Mar 30 06:40 ..\n-rw-r--r--  1 root root 3106 Oct 22  2015 .bashrc\n-rw-r--r--  1 root root  148 Aug 17  2015 .profile\ndrwx------  2 root root 4096 Mar 25 07:51 .ssh"}}]
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (another thing)
[Pipeline] echo
next thing
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: FAILURE

I'm not sure how to handle the case of wanting to stop processing while also returning the salt output. 

protected String run() throws Exception {
  ...
  boolean validFunctionExecution = DoSomeWork();

     if (!validFunctionExecution) {
       listener.error("One or more minion did not return correctly\n");

       run.setResult(Result.FAILURE);
  }

  return saltOutput.toString();

}

Does anyone have any advice or thoughts?

Thanks!

[Robert Sandell]

You could throw a custom Exception with the output contained within.

/B

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4abc0754-31dc-4717-be91-1777f031681a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Christian McHugh]

Would a custom exception allow for returning the requested output, or would that only display in the Jenkins console?

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/KsEzZSoGjo0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2mieb49JAN6mxGBwfNGxdF94to4%3DPxfTr1FyTSu%3Da2yQ%40mail.gmail.com.

[Christian McHugh]

Upon further thought, the custom exception is exactly what it should be. We obviously don't want further processing of output from an error. Thanks much!

[Jesse Glick]

On Thu, Apr 6, 2017 at 6:47 AM, Christian McHugh
<christia...@gmail.com> wrote:
> Would a custom exception allow for returning the requested output

Yes, if you add a `@Whitelisted` getter.

Throwing an exception is the appropriate way to indicate failure. By
default the error will be “thrown up” and fail the build but a script
may choose to catch and handle it somehow, or a `retry` step may
process it, etc. In Declarative Pipeline the appropriate `post`-blocks
will be run before terminating the build.

Historically, some build steps designed for use in freestyle projects
directly set the build result to `FAILURE` and printed a message from
`perform`. Or they may have returned `false` after printing a message.
Neither idiom plays well with Pipeline and is discouraged generally.
(To make it harder to use the latter bad idiom innocently,
`SimpleBuildStep.perform` declares a void return value: you should
rather throw `AbortException` with a detail message.)