There is some api design thinking required - this could be part of the graph of things returned for the stage graph (I imagine this is how the stage view works), but we also want to be able to show on the main dashboard (which is new).

So this may be 2 parts: one is in the stage graph data, the other would be part of the overall job status so that it can show up as favourites (just thinking aloud...)

jamesdumay so is the data returned indicating the fields required out of scope of this? or in scope? not clear

michaelneale right on - "waiting for input" is just the same as running, success, failure, unstable and unknown run statuses.

michaelneale yes, all of that is in scope. I've updated the scoping in the description to eflect that.

jamesdumay michaelneale We should really be calling it PAUSED state. waiting for input really means run and node is in paused state, however specific step inside it could be in waitingForInput state though. This will let us use PAUSED state used for different type of pulse causes. What do you think?

vivek Paused is fine by me.

svanoort We need to associate a FlowNode (StepAtomNode) with an InputStep. Only possible way I can do it now is, WorkflowRun.getExecutions() and then InputStepExecution.getInput() gives me input but there is no public method to get underlying FlowNode from InputStepExecution. Is there way we can do such association?

@vivek I'm shocked to see you really do need all the statuses in pipeline-graph-analysis (PAUSED_PENDING_INPUT)

Two easy ways to get the FlowNode: it'll be a current head (FlowExecution.getCurrentHeads()) and have a PauseAction on it, or mark it when the StatusAndTiming API gives you the node status (it'll be PAUSED_PENDING_INPUT).

svanoort haha, yes

So if I have 3 branches and and all of them have step that's waiting for input, not sure how FlowExecution.getCurrentHeads() will help there? I guess I can make it work by checking status of each atomNode and check if its PAUSED_PENDING_INPUT, assuming I get it on the atomNode thats waiting for input.

vivek The run itself will have an InputAction on it – if present, one (or more!) of its heads will be paused for input.

svanoort Yeah I saw StatusAndTiming.computechunkStatus() doing it and that looks to me a bug. It reports even the inputs busy doing stuff inside shell script are marked as waiting for PAUSED_PENDING_INPUT status. Basically its going to report every paused input as PAUSED_PENDING_INPUT if there is atleast one of the step is waiting for input.

Try this:

Inside StandardChunkVisitor.atomNode() implementation I commute status using this api:

StatusAndTiming.computeChunkStatus(run, before,atomNode,atomNode,after);

Try this script, it will report shell step with sleep inside 'right' branch as PAUSED_PENDING_INPUT status. That is wrong as it should really be IN_PROGRESS.

node {
    stage("parallelStage"){
      parallel left : {
            echo "running"
            def branchInput = input message: 'Please input branch to test against', parameters: [[$class: 'StringParameterDefinition', defaultValue: 'master', description: '', name: 'branch']]
            echo "BRANCH NAME: ${branchInput}"
        }, 
        right : {
            sh 'sleep 10000000'
        }
    }
}