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

Hide specific steps in build view

    XMLWordPrintable

    Details

    • Similar Issues:
    • Epic Link:
    • Sprint:
      Blue Ocean 1.1-beta4, Blue Ocean 1.1

      Description

      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).

        Attachments

          Issue Links

          is related to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-61195 How to avoid "Checks if running on a Unix-like node" in BlueOcean output

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          relates to

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-26987 Hiding certain steps from the "Running Steps" tree

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Task - A task that needs to be done. JENKINS-37324 We would like a more meaningful description of a step

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

            Activity

            Descending order - Click to sort in ascending order
            Hide
            Permalink
            thomaspeitz Thomas Peitz added a comment - - edited

            We are using a shared jenkins library for our company which allows our developers to set up pipelines pretty easily.

            In the configuration of the pipelines we allow to enable / disable steps. Here is an example of a Jenkinsfile:

             

            @Library('ivx@0.1.0') _

             

            buildPipelineKubernetes {

               productionDeployment = false

               lintOpenApi = false

            }

             

            It works pretty good for us and removed the need that developer need to know how Jenkins works. It boosted developer happiness enormously.

             

            Now our deployment pipelines have a lot of steps which are just "white" as they are not executed for the project. For this particular project steps won't be ever executed. So it bloats the view and gives devs bad user experience.

             

            So for us it would be nice to be able to hide steps if they are not executed. Is there any chance we can implement this feature ourselves? - We would take time and try to create a pull request if there is a solution which would be accepted.

             

            We would favor the contribution rather of going back to scripted pipelines again.

             

            Greetings, Thomas 

            Show
            thomaspeitz Thomas Peitz added a comment - - edited We are using a shared jenkins library for our company which allows our developers to set up pipelines pretty easily. In the configuration of the pipelines we allow to enable / disable steps. Here is an example of a Jenkinsfile:   @Library('ivx@0.1.0') _   buildPipelineKubernetes {    productionDeployment = false    lintOpenApi = false }   It works pretty good for us and removed the need that developer need to know how Jenkins works. It boosted developer happiness enormously.   Now our deployment pipelines have a lot of steps which are just "white" as they are not executed for the project. For this particular project steps won't be ever executed. So it bloats the view and gives devs bad user experience.   So for us it would be nice to be able to hide steps if they are not executed. Is there any chance we can implement this feature ourselves? - We would take time and try to create a pull request if there is a solution which would be accepted.   We would favor the contribution rather of going back to scripted pipelines again.   Greetings, Thomas 
            Hide
            Permalink
            gmarquez GMarquez added a comment -

            I think the ability to hide stages is useful. There are several small trivial stages in my pipeline and would like the ability to hide if possible. It would be nice to not see in OceanBlue but perhaps could still log in standard console output (in case any issues). 

            Topic: Add ability to hide skipped stages/ignore stages altogether (support DRY) , similar but not same, I like Timur Batyrshin's suggestion:
            https://issues.jenkins-ci.org/browse/JENKINS-48980?focusedCommentId=345319&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345319

            hide true 
            // hide false // default

            Show
            gmarquez GMarquez added a comment - I think the ability to hide stages is useful. There are several small trivial stages in my pipeline and would like the ability to hide if possible. It would be nice to not see in OceanBlue but perhaps could still log in standard console output (in case any issues).  Topic: Add ability to hide skipped stages/ignore stages altogether (support DRY) , similar but not same, I like Timur Batyrshin's suggestion: https://issues.jenkins-ci.org/browse/JENKINS-48980?focusedCommentId=345319&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345319 hide true  // hide false // default
            Hide
            Permalink
            brunomiguel_teixeira bruno teixeira added a comment - - edited

            I also have a specific use case in my company. We use jenkins & global shared libraries extensively to setup the build's workspaces.

            There are several steps (like creating folders, setting packages feeds, injecting env variables...) that i would like to "hide" from the users so that the commands that the users actually run are not mixed with shared libraries. This is because the steps in the shared libraries are not the end user's concern and often it becomes a bundled mess from the user's perspective.

             

            This is not a hard requirement, merely a UX improvement that i would like.

            Show
            brunomiguel_teixeira bruno teixeira added a comment - - edited I also have a specific use case in my company. We use jenkins & global shared libraries extensively to setup the build's workspaces. There are several steps (like creating folders, setting packages feeds, injecting env variables...) that i would like to "hide" from the users so that the commands that the users actually run are not mixed with shared libraries. This is because the steps in the shared libraries are not the end user's concern and often it becomes a bundled mess from the user's perspective.   This is not a hard requirement, merely a UX improvement that i would like.
            Hide
            Permalink
            anton_yurchenko Anton Yurchenko added a comment -

            I have an example of situations when hiding stages are required.

            Multi-branch pipeline, when push on different branch should create a different slave node in different network segment.

            In order to filter specific use case we are using WHEN condition.

            In such case, there are lots of 'pseudo' stages like "Branch: dev/master", "Branch: dev", "Env: development", "Env: production", "Branch: master".

            Such drill down also breaks the console output as two stages running in UI (for example: Branch: dev and Spawn Slave)

            stage("Branch: dev/master"){
  parallel {
    stage("Env: development") {
      when {
        allOf {
          branch 'dev'
          environment name: 'CHANGE_TARGET', value: ''
        }
      }
      stages {
        stage("Branch: dev"){
          agent {label "development-slave"}
          stages {
            stage("Spawn Slave") {
              steps {
                sh 'command'
              }
              post {
                failure {
                  sh 'command'
                }
                aborted {
                  sh 'command'
                }
              }
            }
            stage("Base Image") {
              steps {
                sh 'command'
              }
              post {
                aborted {
                  sh 'command'
                }
                failure {
                  sh 'command'
                }
              }
            }
            stage("Dev Image") {
              steps {
                sh 'command'
              }
              post {
                aborted {
                  sh 'command'
                }
                failure {
                  sh 'command'
                }
              }
            }
            stage("Notify Team"){
              agent {label "master"}
              steps {
                sh 'command'
              }
            }
            stage('Deploy QA') {
              steps {
                sh 'command'
              }
              post {
                success {
                  sh 'command'
                }
                failure {
                  sh 'command'
                }
                aborted {
                  sh 'command'
                }
                always {
                  sh 'command'
                }
              }
            }
          }
        }
      }
    }
    stage("Env: production") {
      when {
        allOf {
          branch 'master'
          environment name: 'CHANGE_TARGET', value: ''
        }
      }
      stages {
        stage("Branch: master"){
          agent {label "production-slave"}
          stages {
            stage("Spawn Slave") {
              steps {
                sh 'command'
              }
              post {
                failure {
                  sh 'command'
                }
                aborted {
                  sh 'command'
                }
              }
            }
            stage("Base Image") {
              steps {
                sh 'command'
              }
              post {
                aborted {
                  sh 'command'
                }
                failure {
                  sh 'command'
                }
              }
            }
            stage("Prod Image") {
              steps {
                sh 'command'
              }
              post {
                success {
                  sh ' command'
                }
                failure {
                  sh 'command'
                }
                aborted {
                  sh 'command'
                }
                always {
                  sh 'command'
                }
              }
            }
          }
        }
      }
    }
  }
}
            Show
            anton_yurchenko Anton Yurchenko added a comment - I have an example of situations when hiding stages are required. Multi-branch pipeline, when push on different branch should create a different slave node in different network segment. In order to filter specific use case we are using WHEN condition. In such case, there are lots of 'pseudo' stages like "Branch: dev/master", "Branch: dev", "Env: development", "Env: production", "Branch: master". Such drill down also breaks the console output as two stages running in UI (for example: Branch: dev and Spawn Slave) stage( "Branch: dev/master" ){ parallel { stage( "Env: development" ) { when { allOf { branch 'dev' environment name: 'CHANGE_TARGET' , value: '' } } stages { stage( "Branch: dev" ){ agent {label "development-slave" } stages { stage( "Spawn Slave" ) { steps { sh 'command' } post { failure { sh 'command' } aborted { sh 'command' } } } stage( "Base Image" ) { steps { sh 'command' } post { aborted { sh 'command' } failure { sh 'command' } } } stage( "Dev Image" ) { steps { sh 'command' } post { aborted { sh 'command' } failure { sh 'command' } } } stage( "Notify Team" ){ agent {label "master" } steps { sh 'command' } } stage( 'Deploy QA' ) { steps { sh 'command' } post { success { sh 'command' } failure { sh 'command' } aborted { sh 'command' } always { sh 'command' } } } } } } } stage( "Env: production" ) { when { allOf { branch 'master' environment name: 'CHANGE_TARGET' , value: '' } } stages { stage( "Branch: master" ){ agent {label "production-slave" } stages { stage( "Spawn Slave" ) { steps { sh 'command' } post { failure { sh 'command' } aborted { sh 'command' } } } stage( "Base Image" ) { steps { sh 'command' } post { aborted { sh 'command' } failure { sh 'command' } } } stage( "Prod Image" ) { steps { sh 'command' } post { success { sh ' command' } failure { sh 'command' } aborted { sh 'command' } always { sh 'command' } } } } } } } } }
            Hide
            Permalink
            vchijwani Vicky Chijwani added a comment - - edited

            This is a huge problem for us too. We have 100s of developers relying on a global shared library that abstracts out a lot of common functionality, exactly as described in the original issue description. It would be great to see the group proposal above implemented - it would definitely solve most of the problem.

            Show
            vchijwani Vicky Chijwani added a comment - - edited This is a huge problem for us too. We have 100s of developers relying on a global shared library that abstracts out a lot of common functionality, exactly as described in the original issue description. It would be great to see the  group proposal above implemented - it would definitely solve most of the problem.
            10 older comments

              People

              Assignee:
              jamesdumay James Dumay
              Reporter:
              jeanmertz Jean Mertz
              Votes:
              20 Vote for this issue
              Watchers:
              18 Start watching this issue

                Dates

                Created:
                Updated: