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

Not able to create active choice plugin in jenkins pipeline

      We are not able to create an active choice parameter in jenkins pipeline job after upgrading the Jenkins even though it is giving it as an option in parameter dropdown.

      Current Jenkins Version: Jenkins 2.426.1
      Active Choice plugin version: 2.6.4

          [JENKINS-72549] Not able to create active choice plugin in jenkins pipeline

          Had to search the web for that.

          https://stackoverflow.com/a/34372607

          > We were using this content HTML in a Jenkins userContent directory. We recently upgraded to the latest Jenkins 1.625 LTS version & it seems they've introduced new Content security policy which adds the below header to the response headers & the browsers simply decline to execute anything like stylesheets / Javascripts.

          Maybe you are using a newer version of Jenkins? If so, loading external JavaScript files is blocked by Jenkins. There might be some setting to turn that off, and that probably comes with a big warning or something to make sure you will take responsibility for doing so.

          You can reach out to others in their forums (I think Jenkins now has a discourse or some other discussion panel?) and ask about it. I stopped following the development of Jenkins some years ago after I started working more with Python in HPC (behind firewalls, limited Internet) and GitLab and GitHub pipelines/actions.

          Bruno P. Kinoshita added a comment - Had to search the web for that. https://stackoverflow.com/a/34372607 > We were using this content HTML in a Jenkins userContent directory. We recently upgraded to the latest Jenkins 1.625 LTS version & it seems they've introduced new Content security policy which adds the below header to the response headers & the browsers simply decline to execute anything like stylesheets / Javascripts. Maybe you are using a newer version of Jenkins? If so, loading external JavaScript files is blocked by Jenkins. There might be some setting to turn that off, and that probably comes with a big warning or something to make sure you will take responsibility for doing so. You can reach out to others in their forums (I think Jenkins now has a discourse or some other discussion panel?) and ask about it. I stopped following the development of Jenkins some years ago after I started working more with Python in HPC (behind firewalls, limited Internet) and GitLab and GitHub pipelines/actions.

          Brian Hinz added a comment -

          You can easily reproduce what I'm seeing in my more complicated scenario by following this cloudbees tutorial. What you should see is that when you click "Build with parameters" the javascript rendered UI components are visible for a fraction of a second and then disappear. I have not been able to find a way around it, or even why it's happening. No errors in the browser developer console, jenkins logs, etc. Any chance that you could take a look?

          Brian Hinz added a comment - You can easily reproduce what I'm seeing in my more complicated scenario by following this cloudbees tutorial . What you should see is that when you click "Build with parameters" the javascript rendered UI components are visible for a fraction of a second and then disappear. I have not been able to find a way around it, or even why it's happening. No errors in the browser developer console, jenkins logs, etc. Any chance that you could take a look?

          Brian Hinz added a comment -

          I found something interesting. In chrome there is nothing relevant printed to the developer console, but in safari there is a resource loading error:

          [Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (UnoChoice.js.map, line 0)

          I tried adding hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION=true to JAVA_ARGS but it didn't help

          Brian Hinz added a comment - I found something interesting. In chrome there is nothing relevant printed to the developer console, but in safari there is a resource loading error: [Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (UnoChoice.js.map, line 0) I tried adding hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION=true to JAVA_ARGS but it didn't help

          Hi bphinz . Sorry, this was a busy and tiring week at $work. I saw your messages, but didn't have time to read them with calm and reply. I will try over the weekend or tomorrow, but let me thank you for the link to the cloudbees tutorial. I don't remember seeing that before!

          Just to confirm for when I have time, if I follow the tutorial I will be able to reproduce your problem? And could you confirm your browser & Jenkins+plugin versions, please? I will use this info (and any other you may find useful) when trying to reproduce the problem.

          Cheers

          Bruno P. Kinoshita added a comment - Hi bphinz . Sorry, this was a busy and tiring week at $work. I saw your messages, but didn't have time to read them with calm and reply. I will try over the weekend or tomorrow, but let me thank you for the link to the cloudbees tutorial. I don't remember seeing that before! Just to confirm for when I have time, if I follow the tutorial I will be able to reproduce your problem? And could you confirm your browser & Jenkins+plugin versions, please? I will use this info (and any other you may find useful) when trying to reproduce the problem. Cheers

          Brian Hinz added a comment -

          That's correct, following the tutorial you should be able to reproduce what I'm seeing.  Safari 17.2.1, Chrome 120.0.6099.234, Jenkins 2.426.3, Active Choices Plugin 2.8.1.

          Thanks!

          Brian Hinz added a comment - That's correct, following the tutorial you should be able to reproduce what I'm seeing.  Safari 17.2.1, Chrome 120.0.6099.234, Jenkins 2.426.3, Active Choices Plugin 2.8.1. Thanks!

          Brian Hinz added a comment -

          In an effort to try to rule out interactions with other plugins, I created a fresh VM and installed Jenkins 2.426.3 and selected the minimal recommended plugin set and then installed the latest version (2.8.1) of the active-choices plugin but it did not make a difference.  Additionally, I tested with firefox and found that it also emits the same error about the UnoChoice.js.map file.  Also, note that with the minimal plugin set, I had to slightly modify the javascript from the example, replacing "Q" with "jQuery".

          Brian Hinz added a comment - In an effort to try to rule out interactions with other plugins, I created a fresh VM and installed Jenkins 2.426.3 and selected the minimal recommended plugin set and then installed the latest version (2.8.1) of the active-choices plugin but it did not make a difference.  Additionally, I tested with firefox and found that it also emits the same error about the UnoChoice.js.map file.  Also, note that with the minimal plugin set, I had to slightly modify the javascript from the example, replacing "Q" with "jQuery".

          Great (really great and useful) comment bphinz . I have 1-2 hours this evening so I will try to at least follow the tutorial, and try something similar to your comment above. Let's see if it's something simple to fix, or if I can at least understand what's happening.

          Bruno P. Kinoshita added a comment - Great (really great and useful) comment bphinz . I have 1-2 hours this evening so I will try to at least follow the tutorial, and try something similar to your comment above. Let's see if it's something simple to fix, or if I can at least understand what's happening.

          I was able to reproduce the error following the tutorial. Thanks for the hint about the jQuery vs. Q, that helped.

          The first thing I did was to add a debugger statement in the parameter code, to stop the execution and see what was going on. I added it here:

              _.each(items, function (i) {
          debugger
                  Q('.jenkins-parameter-input').append(generateUl(i));
              }); 

          Doing that, saving the configuraiton, and reloading the page, I could see the parameters being correctly rendered.

          After thinking for a while, and looking at the JS console output, I suspected it could be the same bug I saw before: JENKINS-71909

          To confirm it, I changed the Groovy script again, now to produce JavaScript that would add the items only a few seconds later.

          setTimeout(() => {
              _.each(items, function (i) {
                  Q('.jenkins-parameter-input').append(generateUl(i));
              });
          }, 2500) 

          With that, the tutorial example was rendered correctly (2500 worked for me, but for others it could work with more or less time).

          The problem in the linked issue is that some time ago the plug-in got updated to use newer JS code, but also to use Promises asynchronously instead of rendered one parameter at a time, one after the other.

          While doing the Promise way gives in theory better rendering performance, looks like we didn't account for some cases of the plug-in, and how it manipulates the DOM, updates values, and re-renders elements.

          I am afraid your case will require some further investigation in that issue. So feel free to subscribe to that one. I will mark this as blocked by that, and later once that's fixed will check if this can be closed as duplicated, or if the problem persists. Sorry.

          Bruno

          Bruno P. Kinoshita added a comment - I was able to reproduce the error following the tutorial. Thanks for the hint about the jQuery vs. Q, that helped. The first thing I did was to add a debugger statement in the parameter code, to stop the execution and see what was going on. I added it here: _.each(items, function (i) { debugger         Q('.jenkins-parameter-input').append(generateUl(i));     }); Doing that, saving the configuraiton, and reloading the page, I could see the parameters being correctly rendered. After thinking for a while, and looking at the JS console output, I suspected it could be the same bug I saw before: JENKINS-71909 To confirm it, I changed the Groovy script again, now to produce JavaScript that would add the items only a few seconds later. setTimeout(() => {     _.each(items, function (i) {         Q('.jenkins-parameter-input').append(generateUl(i));     }); }, 2500) With that, the tutorial example was rendered correctly (2500 worked for me, but for others it could work with more or less time). The problem in the linked issue is that some time ago the plug-in got updated to use newer JS code, but also to use Promises asynchronously instead of rendered one parameter at a time, one after the other. While doing the Promise way gives in theory better rendering performance, looks like we didn't account for some cases of the plug-in, and how it manipulates the DOM, updates values, and re-renders elements. I am afraid your case will require some further investigation in that issue. So feel free to subscribe to that one. I will mark this as blocked by that, and later once that's fixed will check if this can be closed as duplicated, or if the problem persists. Sorry. Bruno

          Ah, the map file is annoying, but that does not break anything. Would be nice if that worked, but looks like Jenkins filters requests to .map files (I checked and my .js.map is right next to the .js file, but for some reason Jenkins or Jetty or Stapler is not loading that).

          Bruno P. Kinoshita added a comment - Ah, the map file is annoying, but that does not break anything. Would be nice if that worked, but looks like Jenkins filters requests to .map files (I checked and my .js.map is right next to the .js file, but for some reason Jenkins or Jetty or Stapler is not loading that).

          Brian Hinz added a comment -

          Thanks so much for taking the time to investigate, and for providing a temporary workaround.  Using the demo test case I was able to reduce that number down to 100 (below that it was unreliable).  I will try wrapping my production code with the timeout tomorrow (100ms would not be a problem).

          Brian Hinz added a comment - Thanks so much for taking the time to investigate, and for providing a temporary workaround.  Using the demo test case I was able to reduce that number down to 100 (below that it was unreliable).  I will try wrapping my production code with the timeout tomorrow (100ms would not be a problem).

            kinow Bruno P. Kinoshita
            saurabhjaiswal Saurabh
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: