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

Steps with "causeOfBlockage" should show indeterminate indicator

    • iapetus

      In Scope

      • Any step with cause of blockage should show the indeterminate status indicator (same as below but on blue background just like the header)

      Notes

      • See PR-728 for information about the API and discussion about the design.
      • If you are unsure about the design please chat to brody

      Example Pipeline
      This Pipeline will make a "causeOfBlocking" step show on the UI

      pipeline {
        agent none
        stages {
          stage ('first') {
           agent { 
            label 'first' 
           }
           steps{
                sh 'echo "from first"'
            }
          }
        }
      }
      

          [JENKINS-41344] Steps with "causeOfBlockage" should show indeterminate indicator

          Right now we have three different symbols and the only "correct" one I can identify is displayed in the pipeline graph, correct? Further is is correct, that all symbols should be the same?

          Thorsten Scherler added a comment - Right now we have three different symbols and the only "correct" one I can identify is displayed in the pipeline graph, correct? Further is is correct, that all symbols should be the same?

          There is a smallish problem I see with the current implementation


          The "causeOfBlockage" can be only been seen in the detail of a step but not on the generell run level. We use the information of the run to create the DetailsHeader, meaning in the header we will display a running symbol (because that is the information about the run) and in the step we could implement the desired state because we can access the information.

          However that is IMO not really good. It would be better to have the attribute causeOB as well in the run response so we are able to show the correct symbol in the header.

          WDYT vivek jamesdumay?

          Thorsten Scherler added a comment - There is a smallish problem I see with the current implementation The "causeOfBlockage" can be only been seen in the detail of a step but not on the generell run level. We use the information of the run to create the DetailsHeader, meaning in the header we will display a running symbol (because that is the information about the run) and in the step we could implement the desired state because we can access the information. However that is IMO not really good. It would be better to have the attribute causeOB as well in the run response so we are able to show the correct symbol in the header. WDYT vivek jamesdumay ?

          James Dumay added a comment -

          vivek sounds like we need what we discussed on email?

          James Dumay added a comment - vivek sounds like we need what we discussed on email?

          Vivek Pandey added a comment -

          jamesdumay right. Basically backend can add causeOfBloackage field to Run API response. This is going to be present if run's state is QUEUED. In practice its going to be present in general on freestyle job, for pipeline job it might or might not be present as pipeline job's main thread gets executed on master. Regardless Run API get return this value based on whats going on with underlying run model.

          Vivek Pandey added a comment - jamesdumay right. Basically backend can add causeOfBloackage field to Run API response. This is going to be present if run's state is QUEUED. In practice its going to be present in general on freestyle job, for pipeline job it might or might not be present as pipeline job's main thread gets executed on master. Regardless Run API get return this value based on whats going on with underlying run model.

          James Dumay added a comment -

          tscherler there is JENKINS-41579 to get the API you want. Its in vivek's queue.

          James Dumay added a comment - tscherler there is JENKINS-41579 to get the API you want. Its in vivek 's queue.

          jamesdumay I will put it back into the queue until vivek has finished

          Thorsten Scherler added a comment - jamesdumay I will put it back into the queue until vivek has finished

          James Dumay added a comment -

          tscherler no worries - thanks mate!

          James Dumay added a comment - tscherler no worries - thanks mate!

            Unassigned Unassigned
            jamesdumay James Dumay
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: