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

Developer can see node steps within the step listing

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Major Major
    • blueocean-plugin
    • None
    • Blue Ocean 1.2-beta1, Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta3, Blue Ocean 1.2-beta4, Blue Ocean 1.2, Blue Ocean 1.3, Blue Ocean 1.4 - beta 1, Blue Ocean 1.4 - beta 3, Blue Ocean 1.4 - beta 2, Blue Ocean 1.6 - beta 2, Blue Ocean - 1.6 - beta 4

      Scope

      • Show the start of a node step as a Step in the Blue Ocean UI
      • Its description should be
        • its "cause of blockage" when blocked
        • its "agent value" when executed or running
      • Name is "allocate-node" - can we set a more user friendly name?
        • "node" as this matches the step name
      • Statuses
        • Allocating node is queued
        • Allocated node is success
        • Aborted node step is aborted (might need other changes from the refactor)
      • We need at a minimum some unit tests in Blue Ocean

      Out of scope

      • Indenting block scoped steps, etc

          [JENKINS-44981] Developer can see node steps within the step listing

          James Dumay created issue -
          James Dumay made changes -
          Epic Link New: JENKINS-43952 [ 181484 ]
          James Dumay made changes -
          Rank New: Ranked higher
          Andrew Bayer made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Andrew Bayer added a comment - - edited

          So initial investigation:

          • WorkspaceAction actually has all the info you'd want once the node block has actually landed on an agent and is running - it's on the StartStartNode FlowNode for the ExecutorStep, it's got methods like action.getNode() (which returns "" for master and the agent name for anything else) and action.getPath() for the workspace path, etc. It also shows up on StepStartNode for WorkspaceStep, but that's easy enough to distinguish. Buuuuut...
          • That leaves us with needing an action for queuing/cause of blockage, and no way of recording any additional information we might want (like time in queue - though I suppose you could reverse engineer that from the TimingAction on the StepStartNode with the WorkspaceAction and the second StepStartNode with isBody() == true. I dunno - I've never quite grokked why there are two StepStartNode for things like ExecutorStep). So I'm leaning towards a new action after all.
          • "Allocate node" is the display name for ExecutorStep - so if we want something different there, we'd need to special-case ExecutorStep.
          • re: aborted status - probably the simplest thing would be just to check if the StepStartNode for ExecutorStep (a) has a StepEndNode corresponding to it and (b) doesn't have a WorkspaceAction. That'd pretty directly mean it was aborted. But hey, if we're going with a new action, we can embed this too.

          Andrew Bayer added a comment - - edited So initial investigation: WorkspaceAction actually has all the info you'd want once the node block has actually landed on an agent and is running - it's on the StartStartNode FlowNode for the ExecutorStep , it's got methods like action.getNode() (which returns "" for master and the agent name for anything else) and action.getPath() for the workspace path, etc. It also shows up on StepStartNode for WorkspaceStep , but that's easy enough to distinguish. Buuuuut... That leaves us with needing an action for queuing/cause of blockage, and no way of recording any additional information we might want (like time in queue - though I suppose you could reverse engineer that from the TimingAction on the StepStartNode with the WorkspaceAction and the second StepStartNode with isBody() == true . I dunno - I've never quite grokked why there are two StepStartNode for things like ExecutorStep ). So I'm leaning towards a new action after all. "Allocate node" is the display name for ExecutorStep - so if we want something different there, we'd need to special-case ExecutorStep . re: aborted status - probably the simplest thing would be just to check if the StepStartNode for ExecutorStep (a) has a StepEndNode corresponding to it and (b) doesn't have a WorkspaceAction . That'd pretty directly mean it was aborted. But hey, if we're going with a new action, we can embed this too.

          Andrew Bayer added a comment -

          Andrew Bayer added a comment - Preliminary PR up at https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/42
          Andrew Bayer made changes -
          Remote Link New: This issue links to "workflow-durable-task-step #42 (Web Link)" [ 17150 ]
          James Dumay made changes -
          Link New: This issue is duplicated by JENKINS-41829 [ JENKINS-41829 ]
          Andrew Bayer made changes -
          Remote Link New: This issue links to "Blue Ocean PR #1184 (Web Link)" [ 17163 ]
          Andrew Bayer made changes -
          Remote Link New: This issue links to "workflow-api PR #42 (Web Link)" [ 17164 ]

            sophistifunk Josh McDonald
            jamesdumay James Dumay
            Votes:
            3 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: