From 08351bc7ddc5b3035e8260b8baf47f1108baf9c7 Mon Sep 17 00:00:00 2001
From: Kohsuke Kawaguchi <kk@kohsuke.org>
Date: Tue, 20 Sep 2016 16:26:46 -0700
Subject: [PATCH] Clarified that the return value is processed like you expect

---
 doc/step-in-groovy.md | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/step-in-groovy.md b/doc/step-in-groovy.md
index 42f56215c..906230492 100644
--- a/doc/step-in-groovy.md
+++ b/doc/step-in-groovy.md
@@ -47,13 +47,13 @@ package acme;
 import org.jenkinsci.plugins.workflow.cps.steps.ingroovy.GroovyStepExecution
 
 public class RetryStepExecution extends GroovyStepExecution {
-    public void call(Closure body) {
+    public int call(Closure body) {
         int attempt = 0;
         while (true) {
             try {
                 echo "trying ${attempt}"
                 body();
-                return;
+                return attempt;
             } catch (Exception e) {
                 if (attempt++ < step.times) {
                     continue; // retry
@@ -81,7 +81,8 @@ in the source form, so that it can run in the CPS groovy interpreter at the runt
 
 The `call` method on `GroovyStepExecution` subtype defines the actual logic of step.
 If the logic is complex, other methods can be defined on this class and all those methods
-can invoke other steps just like the `call` method can.
+can invoke other steps just like the `call` method can. The return value from the `call`
+method, if any, will be the return value from the step invocation.
 
 `GroovyStepExecution` can access parameters given to `GroovyStep` via the `getStep()` method.
 Note that the actual `GroovyStep` instance is not stored, but rather its invocation form.