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

Parameter references not using params.NAME retained across Replay

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • workflow-cps-plugin
    • None

      My pipeline defines a parameter with sth like:

       

      parameters {
       booleanParam(name: 'RUN_TESTS', defaultValue: false, description: 'Do you want to run the build with tests?')
       }

       

      Printing the param value with

      script {
       if (params.RUN_TESTS) {
       echo "true: $RUN_TESTS"
       }
       else echo "false: $RUN_TESTS"
       }

      shows that the value is always TRUE and the tests are always executed.

       I think this is somewhat related to https://issues.jenkins-ci.org/browse/JENKINS-36543 

       

       

          [JENKINS-49794] Parameter references not using params.NAME retained across Replay

          mm I could reproduce when hitting on REPLAY (as opposite of starting a new build). Can it make any difference? I can do some more tests

          valentina armenise added a comment - mm I could reproduce when hitting on REPLAY (as opposite of starting a new build). Can it make any difference? I can do some more tests

          Ok I can reproduce it in this way.

           

          • create the pipeline job and set the default to true.
          • hit on REPLAY but in the script section, modify the default to false
          • execute

          valentina armenise added a comment - Ok I can reproduce it in this way.   create the pipeline job and set the default to true. hit on REPLAY but in the script section, modify the default to false execute

          Andrew Bayer added a comment -

          Aaaaah, ok, I think I know what's happening here. When you replay the build with job parameter definitions already in place, that results in the run actually having those parameters as part of it - so params.RUN_TESTS in the replayed build isn't getting the default value as it is in the first build, it's getting the actual value of the parameter RUN_TESTS. And that actual value is true, since that was the default value for RUN_TESTS when the build started.

          Andrew Bayer added a comment - Aaaaah, ok, I think I know what's happening here. When you replay the build with job parameter definitions already in place, that results in the run actually having those parameters as part of it - so params.RUN_TESTS in the replayed build isn't getting the default value as it is in the first build, it's getting the actual value of the parameter RUN_TESTS . And that actual value is true, since that was the default value for RUN_TESTS when the build started.

          yeah makes sense but it's not ideal. Is there something we can do or you think it's a non-defect? It makes testing harder

          valentina armenise added a comment - yeah makes sense but it's not ideal. Is there something we can do or you think it's a non-defect? It makes testing harder

          Andrew Bayer added a comment -

          It’s not a defect - this is how it should work. Replay doesn’t mean “undo the previous build and run it fresh”, it just means “run the previous build again”.

          Andrew Bayer added a comment - It’s not a defect - this is how it should work. Replay doesn’t mean “undo the previous build and run it fresh”, it just means “run the previous build again”.

          So say I run a build without specifying parameters, it takes the default ones. Then I replay the same but I modify the script to have different default parameters. From a user perspective it s confusing if it does not take the new default values.

          Maybe there should be condition for which if the replayed run was using the default parameters, those have to be computed again as the script may have changed.

          In any case it s a minor, I let you decide if to close it or put it lowest priority. 

           

          valentina armenise added a comment - So say I run a build without specifying parameters, it takes the default ones. Then I replay the same but I modify the script to have different default parameters. From a user perspective it s confusing if it does not take the new default values. Maybe there should be condition for which if the replayed run was using the default parameters, those have to be computed again as the script may have changed. In any case it s a minor, I let you decide if to close it or put it lowest priority.   

          The way I use the Replay feature is to work through changes to my Jenkinsfile without committing a bunch of intermediate changes that may or may not work. 

          I think the best way to "improve" this would be to add the parameters to the top of the replay page, as if I had clicked "build with parameters". 

          I thought a workaround might be to go into the configuration of that pipeline and either delete the parameter or change its value. In my case, the pipeline is part of a multibranch pipeline and doesn't allow me to save changes to the pipeline.

          If this isn't a feature, there should at least be a workaround...

          Daniel Watrous added a comment - The way I use the Replay feature is to work through changes to my Jenkinsfile without committing a bunch of intermediate changes that may or may not work.  I think the best way to "improve" this would be to add the parameters to the top of the replay page, as if I had clicked "build with parameters".  I thought a workaround might be to go into the configuration of that pipeline and either delete the parameter or change its value. In my case, the pipeline is part of a multibranch pipeline and doesn't allow me to save changes to the pipeline. If this isn't a feature, there should at least be a workaround...

          I also tried going in to the config.xml for that job and manually removing the parameters

          <hudson.model.BooleanParameterDefinition>
           <name>myParameter</name>
           <description>Set to true if you want to live</description>
           <defaultValue>true</defaultValue>
           </hudson.model.BooleanParameterDefinition>

          They were rewritten with the updated default value, but the build still ignores the default value and uses whatever the parameters were for that last build. I can't find a workaround other than committing this file into the repository and using "build with parameters", which isn't really a workaround.

          I guess another workaround would be to just change everywhere in the Jenkinsfile that references the parameter to the desired boolean value. It's not really testing what you plan to commit, but it simulates the desired behavior.

          Daniel Watrous added a comment - I also tried going in to the config.xml for that job and manually removing the parameters <hudson.model.BooleanParameterDefinition> <name>myParameter</name> <description>Set to true if you want to live</description> <defaultValue> true </defaultValue> </hudson.model.BooleanParameterDefinition> They were rewritten with the updated default value, but the build still ignores the default value and uses whatever the parameters were for that last build. I can't find a workaround other than committing this file into the repository and using "build with parameters", which isn't really a workaround. I guess another workaround would be to just change everywhere in the Jenkinsfile that references the parameter to the desired boolean value. It's not really testing what you plan to commit, but it simulates the desired behavior.

          kamil wezka added a comment -

          I just wanted add my comment. Should the script be:

          script {
           if (params.RUN_TESTS == true) {
           echo "true: $RUN_TESTS"
           }
           else echo "false: $RUN_TESTS"
           }
          

          because I think the `params.RUN_TESTS` is just a pointer to parameter reference that is always non null so if you don't use equality operators it is always true. Possibly this is not clear?

           

          kamil wezka added a comment - I just wanted add my comment. Should the script be: script { if (params.RUN_TESTS == true ) { echo " true : $RUN_TESTS" } else echo " false : $RUN_TESTS" } because I think the `params.RUN_TESTS` is just a pointer to parameter reference that is always non null so if you don't use equality operators it is always true. Possibly this is not clear?  

          Quirin Huber added a comment -

          Boolean parameter is not of type boolean but string. (You are comparing apples to pears)

          try: 

          script {
           if (params.RUN_TESTS.toBoolean() == true) {
           echo "true: $RUN_TESTS"
           }
           else echo "false: $RUN_TESTS"
           }
          

          Quirin Huber added a comment - Boolean parameter is not of type boolean but string. (You are comparing apples to pears) try:  script { if (params.RUN_TESTS.toBoolean() == true ) { echo " true : $RUN_TESTS" } else echo " false : $RUN_TESTS" }

            Unassigned Unassigned
            varmenise valentina armenise
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: