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

unclear usage of input step in declarative pipeline

      How is the input step intended to be used in a declarative pipeline using a separate block (JENKINS-48379)? There are several issues with this.

      • The result of the input can only be used in the current stage. Thus, it is not possible to skip multiple stages or use the input value in multiple stages.
      • input and when cannot be combined in all cases. Currently, the result of input can be used in when to skip the stage (cool!). However, if the stage is skipped because of some other criteria, the input is still requested.
      • input cannot be used inside the stage steps as a workaround because the agent would be blocked and it cannot be separated to two steps (approval without agent, handling with agent) because the input result is stage-local.

      If I missed something and the issues can be solved, it would be nice to know and the documentation should be more clear about this. Currently, it seems impossible to create a declarative pipeline with a manual approval step before a deployment when the process also depends on other criteria (e.g. the branch in a multibranch pipeline).

          [JENKINS-49947] unclear usage of input step in declarative pipeline

          Andrew Bayer added a comment -

          The ability to skip multiple stages for a single input result will come along as part of JENKINS-46809 - the architecture makes it not viable to have something that happens in a stage (input, environment, etc) actually carry over as an environment variable to other sibling stages, but sequential nested stages will let you say "here's a parent stage with an input and a when - if the when passes, run this list of other stages".

          Ordering is hard. =) I made the call that there was more value in having the result of input available for when than avoiding the input directive if an unrelated when condition was false. It was either input and then when in evaluation order, or when and then input, so...yeah. Again, once JENKINS-46809 lands, you could do a "parent" stage with the branch when condition, with a single nested stage with the input-based when condition. Not the most elegant syntax, sure, but trade-offs have to be made in order to have the opinionated behavior and structure Declarative provides.

          Andrew Bayer added a comment - The ability to skip multiple stages for a single input result will come along as part of JENKINS-46809 - the architecture makes it not viable to have something that happens in a stage ( input , environment , etc) actually carry over as an environment variable to other sibling stages, but sequential nested stages will let you say "here's a parent stage with an input and a when - if the when passes, run this list of other stages". Ordering is hard. =) I made the call that there was more value in having the result of input available for when than avoiding the input directive if an unrelated when condition was false. It was either input and then when in evaluation order, or when and then input , so...yeah. Again, once JENKINS-46809 lands, you could do a "parent" stage with the branch when condition, with a single nested stage with the input -based when condition. Not the most elegant syntax, sure, but trade-offs have to be made in order to have the opinionated behavior and structure Declarative provides.

          Andreas Klemp added a comment -

          The nested stage is an interesting hint. As far as I see, this is only possible with parallel, so ... yeah ... not optimal. But I'll give it a try with something like this. The downside is, that still only one (sequential) stage can be created.

          stage('Release Approval') {
             when {
               branch 'master'
             }
             parallel {
               stage('Release') {
                 input {
                   # manual approval of release
                 }
                 when {
                   # the release is approved
                 }
                 steps {
                   # release and deployment
                 }
               }
            }
          }

           

          Andreas Klemp added a comment - The nested stage is an interesting hint. As far as I see, this is only possible with parallel, so ... yeah ... not optimal. But I'll give it a try with something like this. The downside is, that still only one (sequential) stage can be created. stage( 'Release Approval' ) { when { branch 'master' } parallel { stage( 'Release' ) { input { # manual approval of release } when { # the release is approved } steps { # release and deployment } } } }  

          Andrew Bayer added a comment -

          aklemp - Yeah, https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/227 (which will hopefully merge/release next month) will give you a better approach.

          Andrew Bayer added a comment - aklemp - Yeah, https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/227 (which will hopefully merge/release next month) will give you a better approach.

          Fernando Nasser added a comment - - edited

          Is it possible to distinguish between 

           
          input { # manual approval of release }

          when {# the release is approved}

           

          and

          when { # the release is approved }

          input {# manual approval of release}
           

          And make the order of appearance determine what prevails?

          I realize that probably there is no notion of ordering for these declarations, only for stage inside stages (several elements of the same type can be ordered).

           

          Perhaps an input condition to use inside when?

          Or an argument to input to tell it to run after when?

          Of course if this is used the input value cannot be used in the when condition.

           

          I am trying to suggest something here as I have already hit the situation where I wanted them reversed, and I guess we'l have something like 50-50% of us wanting it one way or the other.

           

           

          Fernando Nasser added a comment - - edited Is it possible to distinguish between    input { # manual approval of release } when {# the release is approved}   and when { # the release is approved } input {# manual approval of release}   And make the order of appearance determine what prevails? I realize that probably there is no notion of ordering for these declarations, only for stage inside stages (several elements of the same type can be ordered).   Perhaps an input condition to use inside when? Or an argument to input to tell it to run after when? Of course if this is used the input value cannot be used in the when condition.   I am trying to suggest something here as I have already hit the situation where I wanted them reversed, and I guess we'l have something like 50-50% of us wanting it one way or the other.    

          I have a similar issue to fnasser. I have 2 parallel stages, one for dev and one for prod and a when condition determines which stage to run based on the environment. I want to prompt for input in the prod stage only but as the input happens before the when I get prompted for input in regardless of the environment, 

          Liam Fitzpatrick added a comment - I have a similar issue to fnasser . I have 2 parallel stages, one for dev and one for prod and a when condition determines which stage to run based on the environment. I want to prompt for input in the prod stage only but as the input happens before the when I get prompted for input in regardless of the environment, 

          Perhaps add a 'when' configuration option to the 'input' directive?

          This way we could skip the input for certain cases (like for Liam's prod stage) or even have a different input for each case by playing with the right 'when' conditions.

          Fernando Nasser added a comment - Perhaps add a 'when' configuration option to the 'input' directive? This way we could skip the input for certain cases (like for Liam's prod stage) or even have a different input for each case by playing with the right 'when' conditions.

          Andrew Bayer added a comment -

          We're adding the ability to have when be evaluated before input runs over at JENKINS-50880.

          Andrew Bayer added a comment - We're adding the ability to have when be evaluated before input runs over at JENKINS-50880 .

          OK, just for the sake of people who look at this JIRA.

           

          How do we get  when first, input after ?

           

          How do we get  input first, when after ?

           

           

          Fernando Nasser added a comment - OK, just for the sake of people who look at this JIRA.   How do we get  when first, input after ?   How do we get  input first, when after ?    

          Liam Newman added a comment -

          Bulk closing resolved issues.

          Liam Newman added a comment - Bulk closing resolved issues.

            abayer Andrew Bayer
            aklemp Andreas Klemp
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: