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

Active Choice plugin does not handle parameters as expected

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • active-choices-plugin
    • None
    • Active Choices Plug-in 2.8.3
      Jenkins 2.452.1

      We have long used the active choice plugin to render our own Build with Parameters page.

      It has needed a user script to work properly for a long time, but after recent updates it does not work with that either.

      Expected: The rendered page shows default values. When changing from default values, the values are updated.

      Actual: The rendered page shows empty checkboxes, text fields, etc. When changing parameters, the default parameters are still used during execution.

      Attachments: Sample Jenkinsfile, log, screenshots of sample UI and actual UI.

        1. image-2024-07-06-10-43-20-297.png
          image-2024-07-06-10-43-20-297.png
          95 kB
        2. Jenkinsfile.sample
          3 kB
        3. log.txt
          2 kB
        4. UI_actual.jpg
          UI_actual.jpg
          120 kB
        5. UI_sample.jpg
          UI_sample.jpg
          6 kB

          [JENKINS-73239] Active Choice plugin does not handle parameters as expected

          Hi, thanks for the detailed report. I created a new pipeline with your example, then played a bit with the returned Groovy (see screenshot).

          And I believe what's happening here is that https://issues.jenkins.io/browse/JENKINS-71909?filter=14783 is affecting your script now too.

          Previously, the parameters were loaded in order. So your document.getElementById would succeed as the previous parameter ("I", with the "CB_BUILDS") would have been rendered first.

          This issue linked above was a tentative to optimize the rendering of parameters, by rendering them as fast as possible. Which at least sounds like a good idea, but seems like it's creating issues for several users.

          I will not work on your issue for now, and instead will try to use this remaining spare time that I have today/tomorrow to revert that change.

          Please, note that if this takes a bit, it's because I work on the plug-in on my spare time as volunteer, so if family/$work/summer/other OSS project issues/drawing/etc. happen, then I will come back to fix that once I have time to work on this again. But let's hope I can revert, test, and prepare a release soon.

          Cheers

          Bruno P. Kinoshita added a comment - Hi, thanks for the detailed report. I created a new pipeline with your example, then played a bit with the returned Groovy (see screenshot). And I believe what's happening here is that https://issues.jenkins.io/browse/JENKINS-71909?filter=14783 is affecting your script now too. Previously, the parameters were loaded in order. So your document.getElementById would succeed as the previous parameter ("I", with the "CB_BUILDS") would have been rendered first. This issue linked above was a tentative to optimize the rendering of parameters, by rendering them as fast as possible. Which at least sounds like a good idea, but seems like it's creating issues for several users. I will not work on your issue for now, and instead will try to use this remaining spare time that I have today/tomorrow to revert that change. Please, note that if this takes a bit, it's because I work on the plug-in on my spare time as volunteer, so if family/$work/summer/other OSS project issues/drawing/etc. happen, then I will come back to fix that once I have time to work on this again. But let's hope I can revert, test, and prepare a release soon. Cheers

          Hossted added a comment - - edited

          Greetings!

          We are also a community member experiencing the similar issue.

          We hired professional expert(s) to work on this matter since our business case demanded so.
          We submitted the dedicated issue describing the problem(s) in detail here:
          JENKINS-73935

          We hope that the plugin maintainer(s) and / or author(s) will be able to fix the root cause of this issue in the near future.

          In the meantime, we created a separate repository project which contains a workaround for this issue.

          For more information, you can check it out here (on our GitHub).

          Please read in detail if you are interested.
          Also, we provided a patched plugin bundles containing the fix here (on our GitHub).

          But due to security concerns, please, use with caution.

          If you are interested in using the fix before the official fix from the maintainer(s), it would be preferred that you rebuild it yourself instead of using our pre-built bundle we are distributing.

           

          Best regards,
          Hossted

          Hossted added a comment - - edited Greetings! We are also  a community member  experiencing the similar issue. We hired professional expert(s) to work on this matter since our business case demanded so. We submitted the dedicated issue describing the problem(s) in detail here: JENKINS-73935 We hope that the  plugin maintainer(s) and / or author(s) will be able to fix the root cause of this issue  in the near future. In the meantime, we created a separate repository project which contains a workaround for this issue. For more information, you can check it out  here (on our GitHub) . Please read in detail if you are interested. Also, we provided a patched plugin bundles containing the fix  here (on our GitHub) . But due to security concerns, please, use with caution. If you are interested in using the fix before the official fix from the maintainer(s), it would be preferred that you rebuild it yourself instead of using our pre-built bundle we are distributing.   Best regards, Hossted

            kinow Bruno P. Kinoshita
            gtv Daniel
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: