• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • blueocean-plugin
    • None
    • Blue Ocean 1.1-beta4, Blue Ocean 1.1

      We have a company-wide Pipeline setup that uses global pipeline scripts. These scripts do all sort of "behind the scenes" things to make the lives of developers as easy as possible, and make going from first commit to a testable application on Jenkins cost the least amount of code/configuration.

      This is all working great, and developers don't really interact with Jenkins in any way, unless their build failed, and they want to know why.

      Right now, when they click the red cross on GitHub, they are redirected to the build status on the "blue" view, but then they are greeted with multiple steps, that have no meaning to them, and are (given our global scripts work as expected) not the cause of their problems, they just want to see the output of their test run, not all the surrounding steps that make it possible to run their build/test.

      So basically, what I'm looking for is two things:

      1. make step titles more descriptive (but this is already being tackled in another issue)
      2. add the option to hide specific steps from showing up, so devs only see what's relevant

      I did find this issue: https://issues.jenkins-ci.org/browse/JENKINS-26987

      But this is not about the blueocean plugin, and I do believe that the notion "Running Steps is itself intended to be a debugging view" does not apply here, as the blueocean view very much is intended to be as simple as possible for developers to get to the root of their problems, and not for the "Jenkins people" amongst us, who want to drill down into all the possible details there are (for which we still have the classic interface).

          [JENKINS-44094] Hide specific steps in build view

          Jean Mertz created issue -

          James Dumay added a comment -

          jeanmertz alternatively have you thought about wrapping these steps in a stage to differentiate them from the developers portion of the pipeline?

          We are hoping to release JENKINS-37324 in Blue Ocean 1.1 shortly which should improve the step descriptions.

          James Dumay added a comment - jeanmertz alternatively have you thought about wrapping these steps in a stage to differentiate them from the developers portion of the pipeline? We are hoping to release JENKINS-37324 in Blue Ocean 1.1 shortly which should improve the step descriptions.

          Jean Mertz added a comment -

          Thanks for the pointer about the step description, jamesdumay.

          Unfortunately, using different stages is not really the solution we're looking for, since we have a lot of automated steps before/after different stages within our pipeline. So we'd get stages like:

          • pre-setup
          • setup
          • post-setup
          • pre-test
          • test
          • post-test
          • pre-deploy
          • deploy
          • post-deploy

          And then we'd have to inform all devs "don't concern yourself with the pre and post stages, only look at the setup, test and deploy stages".

          This doesn't make for a great user experience.

          Jean Mertz added a comment - Thanks for the pointer about the step description, jamesdumay . Unfortunately, using different stages is not really the solution we're looking for, since we have a lot of automated steps before/after different stages within our pipeline. So we'd get stages like: pre-setup setup post-setup pre-test test post-test pre-deploy deploy post-deploy And then we'd have to inform all devs "don't concern yourself with the pre and post stages, only look at the setup, test and deploy stages". This doesn't make for a great user experience.

          James Dumay added a comment - - edited

          jeanmertz lets explore this a bit more. What happens if one of your automated steps fails? Should we show that step? Should we show all the automated steps? When the automated steps are executing what should the user see?

          James Dumay added a comment - - edited jeanmertz lets explore this a bit more. What happens if one of your automated steps fails? Should we show that step? Should we show all the automated steps? When the automated steps are executing what should the user see?

          Jean Mertz added a comment -

          Good questions jamesdumay.

          Currently, even for steps outside of a stage (at least at the start of a run), you see them, until a step within a stage starts, at which point the other steps go away and you only see the steps within a stage.

          I think hiding a step should be an "advanced" feature which comes with some warnings, one of them being: only hide steps which you know won't fail, or else the "simple" view in the blue job overview will show the job as failed, but not why it failed (you can always use the "escape" button to go to the classic view and see the entire log output).

          That would be the most simplistic MVP version as far as I'm concerned.

          Obviously, showing the failed step when it fails, even if it was hidden at first, would be the preferred solution, as it  will not concern the devs 99.9% of the time when that step succeeds, but if things do go wrong, it can be shown, and they can ask anyone who is knowledgable about the shared-pipeline steps what is going on.

          As far as "what to show while executing" is concerned, I think the same applies as before: I think it makes sense to collapse the step before, but not show/expand the next step yet, until any steps in-between that are hidden are completed.

          This is obviously a trade-off, as hiding anything can mask problems/hangs/etc, but that's I believe the whole point of this feature: as a company, you can have steps that you mark as "irrelevant to the devs" and also "99.9% safe", after which you can hide that step, and improve readability/debugging in most use-cases, while still having a backup (the default Jenkins logs) in case things do go wrong.

          Does that answer your questions?

          Jean Mertz added a comment - Good questions jamesdumay . Currently, even for steps outside of a stage (at least at the start of a run), you see them, until a step within a stage starts, at which point the other steps go away and you only see the steps within a stage. I think hiding a step should be an "advanced" feature which comes with some warnings, one of them being: only hide steps which you know won't fail, or else the "simple" view in the blue job overview will show the job as failed, but not why it failed (you can always use the "escape" button to go to the classic view and see the entire log output). That would be the most simplistic MVP version as far as I'm concerned. Obviously, showing the failed step when it fails, even if it was hidden at first, would be the preferred solution, as it  will not concern the devs 99.9% of the time when that step succeeds, but if things do go wrong, it can be shown, and they can ask anyone who is knowledgable about the shared-pipeline steps what is going on. As far as "what to show while executing" is concerned, I think the same applies as before: I think it makes sense to collapse the step before, but not show/expand the next step yet, until any steps in-between that are hidden are completed. This is obviously a trade-off, as hiding anything can mask problems/hangs/etc, but that's I believe the whole point of this feature: as a company, you can have steps that you mark as "irrelevant to the devs" and also "99.9% safe", after which you can hide that step, and improve readability/debugging in most use-cases, while still having a backup (the default Jenkins logs) in case things do go wrong. Does that answer your questions?

          James Dumay added a comment - - edited

          jeanmertz I am very hesitant of showing and hiding steps based on the authors desired visibility level or state - we should show steps consistently or not at all - however, we could consider something like:

          steps {
             echo 'A visible step'
             group ('Common steps') {
                echo 'shown only within common steps'
                echo 'another step'
             }
             echo 'Another visible step'
          }
          

          So that the user sees:

          • A visible step
          • Common steps
          • Another visible step

          ... instead of the full step listing.

          abayer michaelneale if we had some sanctioned way to group N steps to show as one step, this could also simplify the cases where we have steps that are made of other steps and we get "failing steps" that we don't care about (because we catch them and do something else).

          I believe the docker Pipeline code has something like:

             try {
                 docker run $image
             } catch (Exception e) {
                 docker pull $image
                 docker run $image
             }
          

          The step within the try will show as failed if we don't have the image then have two successful steps after it. We'd want to visualise that block as one "group" so this syntax could be used like so:

          group('docker stuff') {
            try {
                 docker run $image
             } catch (Exception e) {
                 docker pull $image
                 docker run $image
             }
          }
          

          If the steps within the try fail and the rest succeed we would visualise this as one step "docker stuff" that succeeded.

          James Dumay added a comment - - edited jeanmertz I am very hesitant of showing and hiding steps based on the authors desired visibility level or state - we should show steps consistently or not at all - however, we could consider something like: steps { echo 'A visible step' group ( 'Common steps' ) { echo 'shown only within common steps' echo 'another step' } echo 'Another visible step' } So that the user sees: A visible step Common steps Another visible step ... instead of the full step listing. abayer michaelneale if we had some sanctioned way to group N steps to show as one step, this could also simplify the cases where we have steps that are made of other steps and we get "failing steps" that we don't care about (because we catch them and do something else). I believe the docker Pipeline code has something like: try { docker run $image } catch (Exception e) { docker pull $image docker run $image } The step within the try will show as failed if we don't have the image then have two successful steps after it. We'd want to visualise that block as one "group" so this syntax could be used like so: group( 'docker stuff' ) { try { docker run $image } catch (Exception e) { docker pull $image docker run $image } } If the steps within the try fail and the rest succeed we would visualise this as one step "docker stuff" that succeeded.
          James Dumay made changes -
          Assignee New: James Dumay [ jamesdumay ]

          James Dumay added a comment -

          Assigning to myself while I drive out requirements.

          James Dumay added a comment - Assigning to myself while I drive out requirements.
          James Dumay made changes -
          Sprint New: Blue Ocean 1.1-beta3 [ 316 ]
          James Dumay made changes -
          Rank New: Ranked lower

            jamesdumay James Dumay
            jeanmertz Jean Mertz
            Votes:
            27 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated: