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

Capability to add notes to stages (regardless of the actual result)

      As mentioned in JENKINS-26522 it is often useful to provide more information up-front than a simple red or green "this step passed" or "this step failed".

      Adding notes/summarys to a stage would help to provide informations to the user without having to look into the detailed log.

      In our case we share the testsystems between multiple builds but it's still useful to see on which physical server the tests have been run or what stage was executed on wich node or if certain actions have been taken (uploading a artifact to a special store or not).

      All of those decisions are equally valid, lead to successful builds and can be looked up in the log - but they are much more useful to have in the stage-view-plugin (maybe blue ocean some day).

      stage('my-stage') {
        if(decision) {
          // do this
          note ('Done this.')
        } else {
          // do that
          note ('Done that.')
        }
      }

      Maybe even a little markup is allowed to include small icons?

          [JENKINS-46170] Capability to add notes to stages (regardless of the actual result)

          Sam Van Oort added a comment -

          jamesdumay for reference – I like it, myself.  

          Open question on annotations here, one of the design questions that came up for dageissl and others – when you attach an annotation, consider how you think it would make sense for it to behave in the presence of nesting within parallels/other stages.  Does it only tag the last node of the stage?  Just one step?  Does it get propagated up to all following nodes?  To the enclosing stage?  What if you add a later note – does it replace the existing or add a new note?

          These are some of the questions we've been kicking around – I've given it some thought, but would like to know what would make sense to you intuitively as a user.

          Sam Van Oort added a comment - jamesdumay for reference – I like it, myself.   Open question on annotations here, one of the design questions that came up for dageissl and others – when you attach an annotation, consider how you think it would make sense for it to behave in the presence of nesting within parallels/other stages.  Does it only tag the last node of the stage?  Just one step?  Does it get propagated up to all following nodes?  To the enclosing stage?  What if you add a later note – does it replace the existing or add a new note? These are some of the questions we've been kicking around – I've given it some thought, but would like to know what would make sense to you intuitively as a user.

          From my point of view, I am currently focused on the stage-view-plugin in the classic Jenkins UI, which itself provides so much information if you manage so separate your buildsteps.

          That being said a annotation should be displayed inside the Stage block and not on a step.
          The true value would be to see it in the first place - if i want to comment steps I can use echo steps.

          For adding or replacing notes, I'd prefer the replace mode.
          If I want to add something I can use a local variable and extend this before setting the note again. The other way does not work (having only add mode and wanting to replace something set previously).
          This way one can also set some basic layout and fill the content as the stage further progresses (e.g. a table like structure with undefined values at the start, that will get replaced when something clarifies).

          Daniel Geißler added a comment - From my point of view, I am currently focused on the stage-view-plugin in the classic Jenkins UI, which itself provides so much information if you manage so separate your buildsteps. That being said a annotation should be displayed inside the Stage block and not on a step. The true value would be to see it in the first place - if i want to comment steps I can use echo steps. For adding or replacing notes, I'd prefer the replace mode. If I want to add something I can use a local variable and extend this before setting the note again. The other way does not work (having only add mode and wanting to replace something set previously). This way one can also set some basic layout and fill the content as the stage further progresses (e.g. a table like structure with undefined values at the start, that will get replaced when something clarifies).

          James Dumay added a comment -

          svanoort my early thoughts is that this should work using a special step that adds the note to the enclosing stage/parallel.

          James Dumay added a comment - svanoort my early thoughts is that this should work using a special step that adds the note to the enclosing stage/parallel.

          Jesse Glick added a comment -

          It would be great if when using github-branch-source such notes got automatically (well, with some kind of option) turned into commit status notifications on your pull request.

          Jesse Glick added a comment - It would be great if when using github-branch-source such notes got automatically (well, with some kind of option) turned into commit status notifications on your pull request.

          Sam Van Oort added a comment - - edited

          Specific ask from vgaidarji and is to have a 'label' argument for shell step that does something like this:

          sh label:'clear home', script:'rm -rf $WORKSPACE/*'

          This will attach a custom 'MarkerAction' or something (I think NOT a LabelAction because that may have structural implications) - this is used for getDisplayName or whatever and replaces ArgumentAction

          Alternately, something working similarly that does it to general steps in a block like this:

          marker('stuff') {
          echo 'thing'
          sh 'do stuff'
          }

          But this doesn't replace display name necessarily, it may show other stuff.

          Impl note: Blue Ocean's rendering, maybe not just getDisplayName.

          UX: thought, include more than one field

          Sam Van Oort added a comment - - edited Specific ask from vgaidarji and is to have a 'label' argument for shell step that does something like this: sh label:'clear home', script:'rm -rf $WORKSPACE/*' This will attach a custom 'MarkerAction' or something (I think NOT a LabelAction because that may have structural implications) - this is used for getDisplayName or whatever and replaces ArgumentAction Alternately, something working similarly that does it to general steps in a block like this: marker('stuff') { echo 'thing' sh 'do stuff' } But this doesn't replace display name necessarily, it may show other stuff. Impl note: Blue Ocean's rendering, maybe not just getDisplayName. UX: thought, include more than one field

          Jesse Glick added a comment -

          @sam I think you are thinking not of this issue, but of JENKINS-37324.

          Jesse Glick added a comment - @sam I think you are thinking not of this issue, but of JENKINS-37324 .

            Unassigned Unassigned
            dageissl Daniel Geißler
            Votes:
            68 Vote for this issue
            Watchers:
            71 Start watching this issue

              Created:
              Updated: