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

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

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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?

        Attachments

          Issue Links

            Activity

            Hide
            svanoort Sam Van Oort added a comment -

            James Dumay for reference – I like it, myself.  

            Open question on annotations here, one of the design questions that came up for Daniel Geißler 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.

            Show
            svanoort Sam Van Oort added a comment - James Dumay for reference – I like it, myself.   Open question on annotations here, one of the design questions that came up for Daniel Geißler 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.
            Hide
            dageissl 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).

            Show
            dageissl 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).
            Hide
            jamesdumay James Dumay added a comment -

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

            Show
            jamesdumay James Dumay added a comment - Sam Van Oort my early thoughts is that this should work using a special step that adds the note to the enclosing stage/parallel.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            svanoort Sam Van Oort added a comment - - edited

            Specific ask from Veaceslav Gaidarji 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

            Show
            svanoort Sam Van Oort added a comment - - edited Specific ask from Veaceslav Gaidarji 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
            Hide
            jglick Jesse Glick added a comment -

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

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

              People

              • Assignee:
                Unassigned
                Reporter:
                dageissl Daniel Geißler
              • Votes:
                57 Vote for this issue
                Watchers:
                66 Start watching this issue

                Dates

                • Created:
                  Updated: