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

Extended Choice Parameter - Parsing values different for on demand builds and builds started by timer

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Jenkins 1.596
      Extended choice parameter plugin 0.34
      Ubuntu 14.04

      I am observing different behaviours of the plugin when triggering the build manually and when the build is triggered by the timer. The field is configured this way:

      • Parameter type: check boxes
      • Delimiter: (a space)
      • Source for Value: Value = -p,-t,-v
      • Default Value: Value = -p, -t
      • If I run a build manually (leaving the defaults) to print the value of the variable which holds the param the output is:
        + echo -p -t
        -p -t
        
      • If I the build runs with a timer the output is:
        + echo -p, -t
        -p, -t
        

      I've tried the following configuration, which works as expected, however, the default options are not marked when clicking Build with parameters

      • Parameter type: check boxes
      • Delimiter: (a space)
      • Source for Value: Value = -p,-t,-v
      • Default Value: Value = -p -t

          [JENKINS-26490] Extended Choice Parameter - Parsing values different for on demand builds and builds started by timer

          andr00 added a comment -

          I see similiar behavior on Jenkins 1.628, Extended-Choice Parameter Plugin 0.48, OSX 10.10:
          Observed:
          On a manually triggered build, the comma-separated defaults are parsed and applied to the settings checkboxes, then those are joined with the custom delimiter (a semicolon in my case) and passed to the build.

          On a timer or SCM triggered build, any build that does not involve the user confirming the settings, the literal, comma-separated default string is passed to the build.

          Expected: On an automatically triggered build, the default string should be separated on commas and then joined by the custom delimiter before passing to the build.

          andr00 added a comment - I see similiar behavior on Jenkins 1.628, Extended-Choice Parameter Plugin 0.48, OSX 10.10: Observed : On a manually triggered build, the comma-separated defaults are parsed and applied to the settings checkboxes, then those are joined with the custom delimiter (a semicolon in my case) and passed to the build. On a timer or SCM triggered build, any build that does not involve the user confirming the settings, the literal, comma-separated default string is passed to the build. Expected : On an automatically triggered build, the default string should be separated on commas and then joined by the custom delimiter before passing to the build.

          Same problem happen with Jenkins ver. 2.106, Extended-Choice Parameter plugin 0.76

          The character delimiter ; is replace with , when the build is automatically triggered by a timer.

          Alexandre Martel added a comment - Same problem happen with Jenkins ver. 2.106, Extended-Choice Parameter plugin 0.76 The character delimiter ; is replace with , when the build is automatically triggered by a timer.

          Shai added a comment -

          I still see the same behavior

          Jenkins 2.254

          Not sure which version of the plugin is running here, at least 0.78 and there don't seem to be related changes in the code since then.

          Additionally, I tried to set a multiple selection from the schedule, and it didn't work – it looks like there's a validation that forces the value to be exactly one of the options, and in any other case, the parameter in the run is set to empty.

          I tried this both with delimiter set to a space and to a comma, with a "Build with parameters" trigger set from the Jenkins UI to

           

          H 21 * * *  % OTHER_PARAM=other_value; SELECTION=x y; YET_OTHER_PARAM=yet_other_value

          or, of course, with the comma,

          H 21 * * * % OTHER_PARAM=other_value; SELECTION=x,y; YET_OTHER_PARAM=yet_other_value

          In both cases I got an empty parameter in the run, where changing to just y ran fine with it.

          This is the first instance of this job that I'm running, so for now I can just leave the multiple selection in the default value as explained above. However, when I need another one, it looks like I'll have to duplicate the job rather than adding a line in the schedule.

           

          Shai added a comment - I still see the same behavior Jenkins 2.254 Not sure which version of the plugin is running here, at least 0.78 and there don't seem to be related changes in the code since then. Additionally, I tried to set a multiple selection from the schedule, and it didn't work – it looks like there's a validation that forces the value to be exactly one of the options, and in any other case, the parameter in the run is set to empty. I tried this both with delimiter set to a space and to a comma, with a "Build with parameters" trigger set from the Jenkins UI to   H 21 * * * % OTHER_PARAM=other_value; SELECTION=x y; YET_OTHER_PARAM=yet_other_value or, of course, with the comma, H 21 * * * % OTHER_PARAM=other_value; SELECTION=x,y; YET_OTHER_PARAM=yet_other_value In both cases I got an empty parameter in the run, where changing to just y ran fine with it. This is the first instance of this job that I'm running, so for now I can just leave the multiple selection in the default value as explained above. However, when I need another one, it looks like I'll have to duplicate the job rather than adding a line in the schedule.  

            vimil vimil
            david_rubio David Rubio
            Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: