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

Groovy script with default values when job is started by timer

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • active-choices-plugin
    • Active Choices Plug-in version 1.4
      Jenkins ver. 1.652

      I have an Active choice parameter (Multi select) with the following Groovy script

      ['ONE:selected','TWO:selected','TREE:selected','FOUR:selected']
      

      And the following fallback

      ['FALLBACK']
      

      If I start the job with a timer the parameter gets the value ONE:selected, I was expecting ONE,TWO,TREE,FOUR

      This is related to JENKINS-32405 and JENKINS-28735, but has no relation to other Active choice parameters so it might be an easier fix.

          [JENKINS-33473] Groovy script with default values when job is started by timer

          Hi Mattias,

          Thanks for reporting this issue, and for including some Groovy example code to reproduce it.

          The script is evaluated, and the choices returned are: [ONE:selected, TWO:selected, TREE:selected, FOUR:selected]

          • The :selected syntax if used for the UI.
          • When the timer wakes up and prepares to call the job, the script is never evaluated - as normally it would be - since no JS was triggered. So there is not array here yet.
          • Now that Jenkins is executing the job anyway and knows that we are using parameters. So it calls the hudson.model.ParameterDefinition#getDefaultParameterValue method
          • * In hudson.model.ParameterDefinition#getDefaultParameterValue, we return the first element if the script returned any element, or an empty string (the job fails if we pass null).

          I believe the way that the plug-in is treating timer/remote/chained job executions isn't ideal yet. So I'm not sure how to fix your issue right now.

          Will cut a new release, but wanted to provide you some feedback. And as my memory is quite bad, this works as a note to myself, so that in the future when I try to think about a workaround for this issue (and for that one you linked here) I'll re-start from here

          Feel free to ping this issue should you have any suggestions on how to fix it, or any more information that you find may be useful.

          Cheers,
          Bruno

          Bruno P. Kinoshita added a comment - Hi Mattias, Thanks for reporting this issue, and for including some Groovy example code to reproduce it. The script is evaluated, and the choices returned are: [ONE:selected, TWO:selected, TREE:selected, FOUR:selected] The :selected syntax if used for the UI. When the timer wakes up and prepares to call the job, the script is never evaluated - as normally it would be - since no JS was triggered. So there is not array here yet. Now that Jenkins is executing the job anyway and knows that we are using parameters. So it calls the hudson.model.ParameterDefinition#getDefaultParameterValue method * In hudson.model.ParameterDefinition#getDefaultParameterValue, we return the first element if the script returned any element, or an empty string (the job fails if we pass null). I believe the way that the plug-in is treating timer/remote/chained job executions isn't ideal yet. So I'm not sure how to fix your issue right now. Will cut a new release, but wanted to provide you some feedback. And as my memory is quite bad, this works as a note to myself, so that in the future when I try to think about a workaround for this issue (and for that one you linked here) I'll re-start from here Feel free to ping this issue should you have any suggestions on how to fix it, or any more information that you find may be useful. Cheers, Bruno

          Triaging issues, had already no idea what this issue was about. Love that I know myself and leave this notes to myself in the comments triaging 1.5.3, but only including minor issues, as there are other unreleased changes waiting to be published.

          Look forward to 1.5.4. The next development cycle starts immediately after 1.5.3 is released, due to extremely ugly weather here

          Bruno P. Kinoshita added a comment - Triaging issues, had already no idea what this issue was about. Love that I know myself and leave this notes to myself in the comments triaging 1.5.3, but only including minor issues, as there are other unreleased changes waiting to be published. Look forward to 1.5.4. The next development cycle starts immediately after 1.5.3 is released, due to extremely ugly weather here

          > In hudson.model.ParameterDefinition#getDefaultParameterValue, we return the first element if the script returned any element, or an empty string (the job fails if we pass null).

           

          Doesn't work for me. I'm using the following groovy script inside Active Choices Reactive Parameter

          switch (CLOUD_PROVIDER){
             case "AWS":
                return ['c5.xlarge:selected', 'c5.2xlarge', 'c5.4xlarge']
             break
             case "GCP":
                return ['n1-standard-4:selected', 'n1-standard-8', 'n1-standard-16']
             break
          }
          

          CLOUD_PROVIDER it's Active Choices Parameter with simple script

          return ['AWS:selected', 'GCP']

          But when job triggered by timer it always return empty string. Did I miss something?

          Active choice plugin - 2.1, Jenkins - 2.164.3

          Alex Domoradov added a comment - > In hudson.model.ParameterDefinition#getDefaultParameterValue, we return the first element if the script returned any element , or an empty string (the job fails if we pass null).   Doesn't work for me. I'm using the following groovy script inside Active Choices Reactive Parameter switch (CLOUD_PROVIDER){ case "AWS" : return [ 'c5.xlarge:selected' , 'c5.2xlarge' , 'c5.4xlarge' ] break case "GCP" : return [ 'n1-standard-4:selected' , 'n1-standard-8' , 'n1-standard-16' ] break } CLOUD_PROVIDER it's Active Choices Parameter with simple script return [ 'AWS:selected' , 'GCP' ] But when job triggered by timer it always return empty string. Did I miss something? Active choice plugin - 2.1, Jenkins - 2.164.3

          Pawel Xj added a comment -

          We migrated from Extended Choice Parameter which we liked more than this one.

          I must admint that this issue is really annoying

          if build is started by timer and if groovy script return any option which ":selected" then it seems to work fine.

          But we have few jobs which checkboxes where by default nothing is selected. Then if build is started by timer it return first value istead of empty.

           

          After spending half of the day I found some workaround

          if ( jenkinsParameter.detectProject() == null) return [] 

          and of course you need to approve this method
          method org.biouno.unochoice.AbstractScriptableParameter detectProject

          Pawel Xj added a comment - We migrated from Extended Choice Parameter which we liked more than this one. I must admint that this issue is really annoying if build is started by timer and if groovy script return any option which ":selected" then it seems to work fine. But we have few jobs which checkboxes where by default nothing is selected. Then if build is started by timer it return first value istead of empty.   After spending half of the day I found some workaround if ( jenkinsParameter.detectProject() == null ) return [] and of course you need to approve this method method org.biouno.unochoice.AbstractScriptableParameter detectProject

          Hi xjjx 

          > We migrated from Extended Choice Parameter which we liked more than this one.

          Nothing wrong with that. I use that plug-in too, and we have features that were implemented as I or others needed a similar feature from Extended Choice.

          > After spending half of the day I found some workaround

          The main issue for me is that I'm not using Timers with the plug-in, so I would need to have time to spend on reproducing it, reading the Jenkins API/code/docs, and implementing a fix.

          If your solution, for example, has no side-effects (i.e. doesn't break anything else if added directly to the plug-in), then besides adding that in the logic of the plug-in, I'd have to write a short test too.

          So all in all, it annoys me too that I do not have as much time as I would like to implement everything here... but I volunteer for the plug-in as at $work I am not using the plug-in, and I still need to eat and pay rent/etc.

          Thanks for the workaround, that might be helpful when time comes to fix this. Cheers

          Bruno P. Kinoshita added a comment - Hi xjjx   > We migrated from Extended Choice Parameter which we liked more than this one. Nothing wrong with that. I use that plug-in too, and we have features that were implemented as I or others needed a similar feature from Extended Choice. > After spending half of the day I found some workaround The main issue for me is that I'm not using Timers with the plug-in, so I would need to have time to spend on reproducing it, reading the Jenkins API/code/docs, and implementing a fix. If your solution, for example, has no side-effects (i.e. doesn't break anything else if added directly to the plug-in), then besides adding that in the logic of the plug-in, I'd have to write a short test too. So all in all, it annoys me too that I do not have as much time as I would like to implement everything here... but I volunteer for the plug-in as at $work I am not using the plug-in, and I still need to eat and pay rent/etc. Thanks for the workaround, that might be helpful when time comes to fix this. Cheers

            kinow Bruno P. Kinoshita
            attiand Mattias Andersson
            Votes:
            9 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: