Skip to content

Implement Steps service `Status` API

Implement the Status() API as per the Blueprint (mostly). I've added a Message field to the Status message to capture errors that might not be reflected in the any StepResult.ExecResult.ExitCode, like cancellation before step execution starts.

Computing an overall ExitCode is a bit weird: Only Exec-type steps have an exit-code (which makes sense, since they are the only ones that produce an exit code). This means we have to look at all StepResults for exit-codes, specifically non-zero exit codes. We can't for e.g. just look at the StepResult for the root step. It also means that if multiple exec-Steps have non-zero exit-codes, it's not clear which one to use. And of course there's the case that no steps have finished execution at the time Status() is called, and in that case a value of math.MinInt32 is used for the exit-code to mean "this value was not set", We could alternatively just use 0, or use a pointer to an int for that field.

Another point worth noting is that calls to Status() will return a status computed at the time the API was called! This means some the Status values can change. Specifically, some fields are only populated when the whole execution finishes (e.g. end-time), and some fields can change value throughout the execution (e.g. exit-code). For example, in a Step with two exec-type sub-Steps, the first step could have exit-code 0, and if Status is called at this point, the Status.ExitCode will be 0. Then the second Step could exit with 1, and if status is called again, Status.ExitCode will be 1. Alternative we could compute the ExitCode once, when the entire step execution finishes, and consider the ExitCode uninitialized until that point.

  • Best reviewed commit-at-a-time
  • Closes #37
Edited by Axel von Bertoldi

Merge request reports