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

Add ability to hide skipped stages/ignore stages altogether (support DRY)

      我已经在其他票证和网站上多次看到这一点,但我找不到专门解决它的票证。(所以希望我不只是简单地错过它)

       

      问题:给定几个不同的存储库,具有执行不同阶段的不同分支,没有简单的方法可以基于某些配置修改管道以保持声明性管道 DRY。

       

      简单的例子:

      • 分支 1 阶段:A -> B -> C
      • 分支 2 阶段:A -> B -> D
      • 分支 3 个阶段:A -> B -> C -> D

      目前,这需要定义 3 个不同的管道,这意味着冗余代码存在于不同的文件中,进而增加了发生错误的可能性。在更复杂的情况下,根本不可能查看对所有不同管道组合的更改。

      例如,在阶段中使用“when”是解决此问题的一种方法,但这会导致在分支构建中看到“部署”阶段而不是部署的开发人员感到困惑。此外,对于复杂的场景,可能会有许多跳过的阶段,这些阶段总是会被跳过,并简单地向可视化添加不必要的冗长。

      另一种解决方法是使用脚本化管道,但使用声明式提供的许多可视化功能不存在或始终无法正常工作。此外,由于阶段列表不是预先确定的,阶段视图总是在构建期间重置。

       

      我能想到的解决方案有两种:

      1. 提供修改“何时”行为的能力,让蓝海可视化完全忽略它。这种方法的问题在于,我相信在执行阶段时会评估“何时”条件,但阶段列表是在评估管道时在开始时确定的。这可能实际上可以实现,只是简单地在可视化中隐藏舞台而不是完全忽略它。例如:(这可能会大大改进,但它表明了这一点):
        config = [ 
            skipStage2 : true 
        ] 
        
        pipeline { 
            agent any 
            stage { 
                stage( "Stage 1" ) { ... } 
                stage( "Stage 2" ) { 
                    when { 
                         showOnlyWhen { 
                             expression { return !config.skipStage2 } // 在执行阶段
                         } 
                     } 
                    ... 
                } 
            } 
        }
      1.  添加另一个预先评估以确定阶段列表的指令。如果阶段列表从构建到构建发生变化,这与整个声明性管道发生变化并且存在不同阶段没有什么不同。例如:
        config = [ 
            skipStage2 : true , // 当existsStage2 = false
             existsStage2 : false 
        ]
        
        管道{ 
            agent any 
            stage { 
                stage( "Stage 1" ) { ... } 
                stage( "Stage 2" ) { 
                    when { 
                        expression { return ! config.skipStage2} //在执行阶段之后评价
                    }
                    存在{
                        表达式{返回config.existsStage2} //评估的前期确定是否 这舞台甚至运行
                    } 
                    ... 
                } 
            } 
        }

         

       

          [JENKINS-48980] Add ability to hide skipped stages/ignore stages altogether (support DRY)

          Andrew Bayer added a comment -

          I think the best place to discuss/address this would be in Blue Ocean - so I'm moving this to that component. I don't think we want to change when behavior in Declarative itself, so visualization changes are the best option. Declarative already provides information on why a stage was skipped (i..e, skipped due to earlier failure, skipped due to when condition, etc) that Blue Ocean can access.

          Andrew Bayer added a comment - I think the best place to discuss/address this would be in Blue Ocean - so I'm moving this to that component. I don't think we want to change when behavior in Declarative itself, so visualization changes are the best option. Declarative already provides information on why a stage was skipped (i..e, skipped due to earlier failure, skipped due to when condition, etc) that Blue Ocean can access.

          pixman20 added a comment - - edited

          abayer, Is there already information provided by declarative so that Blue Ocean would know when to suppress showing the stage (rather than just marking it skipped)?
          Also, I was thinking that it would need to be added to declarative in order to hide the stages from the stage view on the main job page.

          pixman20 added a comment - - edited abayer , Is there already information provided by declarative so that Blue Ocean would know when to suppress showing the stage (rather than just marking it skipped)? Also, I was thinking that it would need to be added to declarative in order to hide the stages from the stage view on the main job page.

          Michael Neale added a comment -

          The problem is - before skipped were show, people would complain about not showing them (assuming going with the single pipeline). Adding more config/complexity for this case.. maybe the multiple pipeline is the way if the developers really don't want to know about deploy? not keen on this as it is at all based on past history. 

          Michael Neale added a comment - The problem is - before skipped were show, people would complain about not showing them (assuming going with the single pipeline). Adding more config/complexity for this case.. maybe the multiple pipeline is the way if the developers really don't want to know about deploy? not keen on this as it is at all based on past history. 

          Timur Batyrshin added a comment - - edited

          abayer, this could be done as an additional modificator to the pipeline, something like this:

          pipeline {
            stages {
              stage('hide me') {
                when { expression { false } }
                hide true
                steps { ... }
              }
              stage('skip me but show me') {
                when { expression { false } }
          //    hide false // default
                steps { ... }
              }
              stage('run me and show me') {
                when { expression { true } }
                hide true // hiding doesn't make sense when stage is not skipped
                steps { ... }
              }
            }
          }
          
          

          My use case is a pipeline library consisting of dozen steps which is shared across dozens different projects.

          Some steps are skipped based on branch name and showing them up is ok.

          Some steps are skipped based on project type and I would want to hide them.

           

          I could keep a copy of the pipeline for every project type but that doesn't look like very much viable option as the pipeline is 700+ LOC and I don't see much options of reducing it below 400-500 LOC which is quite much too.

          Copying becomes error prone and increases maintenance when doing changes to the pipeline stages common for all pipelines.

          So I see 2 viable options for improvement:

          Any thoughts?

           

           

          Timur Batyrshin added a comment - - edited abayer , this could be done as an additional modificator to the pipeline, something like this: pipeline { stages { stage( 'hide me' ) { when { expression { false } } hide true steps { ... } } stage( 'skip me but show me' ) { when { expression { false } } // hide false // default steps { ... } } stage( 'run me and show me' ) { when { expression { true } } hide true // hiding doesn't make sense when stage is not skipped steps { ... } } } } My use case is a pipeline library consisting of dozen steps which is shared across dozens different projects. Some steps are skipped based on branch name and showing them up is ok. Some steps are skipped based on project type and I would want to hide them.   I could keep a copy of the pipeline for every project type but that doesn't look like very much viable option as the pipeline is 700+ LOC and I don't see much options of reducing it below 400-500 LOC which is quite much too. Copying becomes error prone and increases maintenance when doing changes to the pipeline stages common for all pipelines. So I see 2 viable options for improvement: add the ability to hide some changes add the ability to offload stages to external files ( https://issues.jenkins-ci.org/browse/JENKINS-42224 ) Any thoughts?    

          I would also find it very useful. I like the syntax proposed by erthad.

          My use case is the same. A default pipeline for many projects. They build the code the same way, but some projects are only pushing artifacts, other projects are building docker image.

          Romain Marteau added a comment - I would also find it very useful. I like the syntax proposed by erthad . My use case is the same. A default pipeline for many projects. They build the code the same way, but some projects are only pushing artifacts, other projects are building docker image.

          Mike Dukes added a comment -

          +1 for this request.

          My scenario is that we have different pipeline behaviour based on our branching strategy, and visually it makes developers confused when they see more steps, especially when they see "Production".

          Example:

          • master branch pipeline: Build > Test > Deploy to X > promote to Release branch
          • release branch pipeline: Build > Test > Deploy to Prod
          • whats seen: Build > Test > Deploy to X > Promote to Release > Deploy to Prod even though not all jobs are run

          I like Build and Test to be written once so we keep consistency, so control this with when statements. In my case I'm happy to hide all steps that aren't run, so the simplest feature for me would be a tickbox in the job configuration e.g. "Blue Ocean hide jobs which aren't run", but understand this might not be sufficient based on the other comments! So would be happy with whatever ability here.

          Mike Dukes added a comment - +1 for this request. My scenario is that we have different pipeline behaviour based on our branching strategy, and visually it makes developers confused when they see more steps, especially when they see "Production". Example: master branch pipeline: Build > Test > Deploy to X > promote to Release branch release branch pipeline: Build > Test > Deploy to Prod whats seen: Build > Test > Deploy to X > Promote to Release > Deploy to Prod even though not all jobs are run I like Build and Test to be written once so we keep consistency, so control this with when statements. In my case I'm happy to hide all steps that aren't run, so the simplest feature for me would be a tickbox in the job configuration e.g. "Blue Ocean hide jobs which aren't run", but understand this might not be sufficient based on the other comments! So would be happy with whatever ability here.

          michaelneale maybe your comment comment-325723 was actual when everybody used simple pipelines. But this feature is again actual with multibranch pipelines. We have one jenkins file for all branches, tags and pull requests, so this pipeline contains many different stages for different git branches, tags and pullrequests. So this is really helpful to hide skipped stages when they doesn't related to the current build.

          I think the best option is what erthad suggested, but I think the parameter should be more meaningful like `hideWhenSkipped` or just `hideSkipped` with default value 'false' and let users to decide by itself to show/hide skipped stage based on their use case:

           

          pipeline {
            stages {
              stage('hide me') {
                when { expression { false } }
                hideWhenSkipped true
                steps { ... }
              }
            }
          }
          

           

          Yauheni Batsianouski added a comment - michaelneale  maybe your comment comment-325723 was actual when everybody used simple pipelines. But this feature is again actual with multibranch pipelines. We have one jenkins file for all branches, tags and pull requests, so this pipeline contains many different stages for different git branches, tags and pullrequests. So this is really helpful to hide skipped stages when they doesn't related to the current build. I think the best option is what  erthad  suggested, but I think the parameter should be more meaningful like `hideWhenSkipped` or just `hideSkipped` with default value 'false' and let users to decide by itself to show/hide skipped stage based on their use case:   pipeline { stages { stage( 'hide me' ) { when { expression { false } } hideWhenSkipped true steps { ... } } } }  

          oded baruch added a comment -

          Any chance one of these suggestions will kick in?

          oded baruch added a comment - Any chance one of these suggestions will kick in?

          Massimeddu added a comment -

          This is also important for our organization. Hope it could pick up soon.

          Massimeddu added a comment - This is also important for our organization. Hope it could pick up soon.

            olamy Olivier Lamy
            pixman20 pixman20
            Votes:
            26 Vote for this issue
            Watchers:
            27 Start watching this issue

              Created:
              Updated: