When configuring a workflow job and adding a active-choices parameter to the job, the script section is blank/empty. This also seems to happen when the active-choices plugin is used with another plugin that has a groovy script textarea.

          [JENKINS-29407] Active Choices plugin doesn't work with Workflow Plugin

          Hi Jason

          It is a known issue (see JENKINS-28735), and I haven't found a way to fix it yet.

          Currently, the parameter uses the Jenkins UI, read and parsing the HTML DOM to find other parameters. When used in scripts or from other plug-ins, if the Jenkins UI is not used, it will simply evaluate the Groovy script with no parameters.

          Bruno P. Kinoshita added a comment - Hi Jason It is a known issue (see JENKINS-28735 ), and I haven't found a way to fix it yet. Currently, the parameter uses the Jenkins UI, read and parsing the HTML DOM to find other parameters. When used in scripts or from other plug-ins, if the Jenkins UI is not used, it will simply evaluate the Groovy script with no parameters.

          Jason Kulatunga added a comment - - edited

          I've added an attachment with the issue i'm referencing. Its different than the link you provided. The error is happening in the Job configure page.

          Jason Kulatunga added a comment - - edited I've added an attachment with the issue i'm referencing. Its different than the link you provided. The error is happening in the Job configure page.

          Code changed in jenkins
          User: Bruno P. Kinoshita
          Path:
          src/main/resources/org/biouno/unochoice/CascadeChoiceParameter/config.jelly
          src/main/resources/org/biouno/unochoice/ChoiceParameter/config.jelly
          src/main/resources/org/biouno/unochoice/DynamicReferenceParameter/config.jelly
          http://jenkins-ci.org/commit/active-choices-plugin/2e53bed2aeb88e5cb83e759f5d9a8f055af32931
          Log:
          JENKINS-29407 Double check before using instance! Check if the it variable is available, or the configuration scripts can be emptied!

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Bruno P. Kinoshita Path: src/main/resources/org/biouno/unochoice/CascadeChoiceParameter/config.jelly src/main/resources/org/biouno/unochoice/ChoiceParameter/config.jelly src/main/resources/org/biouno/unochoice/DynamicReferenceParameter/config.jelly http://jenkins-ci.org/commit/active-choices-plugin/2e53bed2aeb88e5cb83e759f5d9a8f055af32931 Log: JENKINS-29407 Double check before using instance! Check if the it variable is available, or the configuration scripts can be emptied!

          Edward Wijaya added a comment -

          Hi Bruno,

          I'm currently using Workflow that populates dynamically 2 parameters.
          This is similar to the 2nd example "Active Choices Reactive Parameter: Configuration Options (Example 02)" where we select site and then the list of cities will be populated.

          This still does not work in Jenkins Workflow as Jason reported. Can you prioritise to fix this problem?
          Thanks alot for your help, kind of need this urgently.

          I'm using Jenkins ver. 1.632, and Active choice ver 1.2

          Edward

          Edward Wijaya added a comment - Hi Bruno, I'm currently using Workflow that populates dynamically 2 parameters. This is similar to the 2nd example "Active Choices Reactive Parameter: Configuration Options (Example 02)" where we select site and then the list of cities will be populated. This still does not work in Jenkins Workflow as Jason reported. Can you prioritise to fix this problem? Thanks alot for your help, kind of need this urgently. I'm using Jenkins ver. 1.632, and Active choice ver 1.2 Edward

          Edward Wijaya added a comment -

          Sorry if i hijacked this issue, i dont know if there is a rule to open a new issue for discovered problem OR it is ok to reopen.
          Let me know if you want me to open a new issue, for the moment i reopened the issue.

          Edward Wijaya added a comment - Sorry if i hijacked this issue, i dont know if there is a rule to open a new issue for discovered problem OR it is ok to reopen. Let me know if you want me to open a new issue, for the moment i reopened the issue.

          That's all right to reopen it I'm starting a cycle to work on the plug-in, but have other issues to tackle first. Not sure if I will be able to include this one in the next release. In case you have a pull request let me know and I'll try to review/merge it.

          Bruno

          Bruno P. Kinoshita added a comment - That's all right to reopen it I'm starting a cycle to work on the plug-in, but have other issues to tackle first. Not sure if I will be able to include this one in the next release. In case you have a pull request let me know and I'll try to review/merge it. Bruno

          Edward Wijaya added a comment -

          Thanks for your reply. May i ask what is the issue in this ticket?
          I saw your reply to Jason, but it seems that it does not relate to the issue he is describing.
          What i'm seeing in the Jenkins is that the script section is totally gone. I tried to create a Freestyle job and write the dynamic parameters which works.
          Then i tried to copy the job config.xml section which contain the script to the workflow, but it does not work. It didnt recognize the script nor it shows the UI.

          If you can point out the issue, let me try to check on it if i can give a pull request. Else if its too complex, i will have to find other way to implement it.

          Edward

          Edward Wijaya added a comment - Thanks for your reply. May i ask what is the issue in this ticket? I saw your reply to Jason, but it seems that it does not relate to the issue he is describing. What i'm seeing in the Jenkins is that the script section is totally gone. I tried to create a Freestyle job and write the dynamic parameters which works. Then i tried to copy the job config.xml section which contain the script to the workflow, but it does not work. It didnt recognize the script nor it shows the UI. If you can point out the issue, let me try to check on it if i can give a pull request. Else if its too complex, i will have to find other way to implement it. Edward

          Hi luciuszhun

          If memory serves well, the issue here is that the plug-in uses the HTML DOM, to retrieve other parameters' values.

          I don't know the pipelines plug-in API well enough, but I believe you don't always get parameters rendered on the UI.

          If you have one step calling the other, and there's no DOM, the plug-in will simply display empty values, or whatever fall back you have configured in your job configuration.

          So the challenge is to find a way that we can run a pipeline, and have some way to tell the plug-in about other parameters' values in the pipeline. Perhaps we could add an abstraction layer, before the DOM interaction.

          If the DOM is available, then we use it. Otherwise, we have an alternative mechanism that will either read the job configuration, or receive some context from the pipeline runner, or something along this line.

          Hope that helps

          Bruno P. Kinoshita added a comment - Hi luciuszhun If memory serves well, the issue here is that the plug-in uses the HTML DOM, to retrieve other parameters' values. I don't know the pipelines plug-in API well enough, but I believe you don't always get parameters rendered on the UI. If you have one step calling the other, and there's no DOM, the plug-in will simply display empty values, or whatever fall back you have configured in your job configuration. So the challenge is to find a way that we can run a pipeline, and have some way to tell the plug-in about other parameters' values in the pipeline. Perhaps we could add an abstraction layer, before the DOM interaction. If the DOM is available, then we use it. Otherwise, we have an alternative mechanism that will either read the job configuration, or receive some context from the pipeline runner, or something along this line. Hope that helps

          Code changed in jenkins
          User: Bruno P. Kinoshita
          Path:
          src/main/java/org/biouno/unochoice/AbstractScriptableParameter.java
          src/main/java/org/biouno/unochoice/util/Utils.java
          http://jenkins-ci.org/commit/active-choices-plugin/766aa42860491aedab12b72f366d472826798576
          Log:
          JENKINS-29407: make helper variables visible to pipelines jobs

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Bruno P. Kinoshita Path: src/main/java/org/biouno/unochoice/AbstractScriptableParameter.java src/main/java/org/biouno/unochoice/util/Utils.java http://jenkins-ci.org/commit/active-choices-plugin/766aa42860491aedab12b72f366d472826798576 Log: JENKINS-29407 : make helper variables visible to pipelines jobs

          Started working on this issue today after a long time (it's quite a storm outside anyway). Alas I couldn't find a good solution yet. Branch: https://github.com/jenkinsci/active-choices-plugin/tree/pipeline-support

          Started by fixing the variables jenkinsBuild and jenkinsProject for pipeline builds (which also removes one deprecated method call at least).

          Then created a few pipeline jobs to test the plug-in. As expected, when you add "This build is parameterized", everything works as expected.

          But if you call another job, the cascaded parameters do not receive updates from other parameters. The behaviour is the same you would see by scheduling a job with AC cascaded parameters.

          When a job is scheduled without the UI, we could - in theory - still create the values for parameters, and then notify other parameters about the update, or read the value of the referenced parameters. These are the two options we have I think.

          Alternative 1) notify other parameters about the update

          When the UI is available, and we have JavaScript and the DOM, what we created in Active Choices is a push based parameters update. Where one parameter is changed, and then kindly goes to each of its children parameters and tells them that there is an update available.

          We are able to do that, because we basically hijack each parameter in the UI that we need, and add event listeners to notify parameters. But in the Java side, there is no option for doing the same.

          We could modify our parameters in Active Choices to notify other parameters in the "default value" method, or even check what was the "Cause" that triggered the job, and identify when the UI/DOM is not available... but we don't have an option to update other parameters such as String Parameter. Nor we have any extension point in Jenkins for that.

          Alternative 2) read the value of the referenced parameters

          In this case, you have something like PARAM1 – is referenced by – > PARAM2. In the UI, you must have PARAM1 configured before PARAM2, so that PARAM1 is executed first.

          The order is kept in timer scheduled builds. So PARAM1 is executed fine. But when PARAM2 (which is either a HTML referenced parameter, or a cascade choice parameter) is executed, the value of its referenced parameters is not updated.

          When you have the UI, this update happens via JavaScript.

          Inside the PARAM2 execution, you can retrieve the project (we already do that, to put the jenkinsProject variable in the context for Groovy). And via the project, you can retrieve the other parameters. Amongst these parameters, you can find the one that is referenced by PARAM2, i.e. PARAM1.

          However, there is no value associated with PARAM1. The value is never stored in some context or session that can be accessed by other parameters. I believe because Jenkins was not designed for that, which makes sense I think.

           

          Bruno P. Kinoshita added a comment - Started working on this issue today after a long time (it's quite a storm outside anyway). Alas I couldn't find a good solution yet. Branch: https://github.com/jenkinsci/active-choices-plugin/tree/pipeline-support Started by fixing the variables jenkinsBuild and jenkinsProject for pipeline builds (which also removes one deprecated method call at least). Then created a few pipeline jobs to test the plug-in. As expected, when you add "This build is parameterized", everything works as expected. But if you call another job, the cascaded parameters do not receive updates from other parameters. The behaviour is the same you would see by scheduling a job with AC cascaded parameters. When a job is scheduled without the UI, we could - in theory - still create the values for parameters, and then notify other parameters about the update, or read the value of the referenced parameters. These are the two options we have I think. Alternative 1) notify other parameters about the update When the UI is available, and we have JavaScript and the DOM, what we created in Active Choices is a push based parameters update. Where one parameter is changed, and then kindly goes to each of its children parameters and tells them that there is an update available. We are able to do that, because we basically hijack each parameter in the UI that we need, and add event listeners to notify parameters. But in the Java side, there is no option for doing the same. We could modify our parameters in Active Choices to notify other parameters in the "default value" method, or even check what was the "Cause" that triggered the job, and identify when the UI/DOM is not available... but we don't have an option to update other parameters such as String Parameter. Nor we have any extension point in Jenkins for that. Alternative 2) read the value of the referenced parameters In this case, you have something like PARAM1 – is referenced by – > PARAM2. In the UI, you must have PARAM1 configured before PARAM2, so that PARAM1 is executed first. The order is kept in timer scheduled builds. So PARAM1 is executed fine. But when PARAM2 (which is either a HTML referenced parameter, or a cascade choice parameter) is executed, the value of its referenced parameters is not updated. When you have the UI, this update happens via JavaScript. Inside the PARAM2 execution, you can retrieve the project (we already do that, to put the jenkinsProject variable in the context for Groovy). And via the project, you can retrieve the other parameters. Amongst these parameters, you can find the one that is referenced by PARAM2, i.e. PARAM1. However, there is no value associated with PARAM1. The value is never stored in some context or session that can be accessed by other parameters. I believe because Jenkins was not designed for that, which makes sense I think.  

          Previous comment was also a memory note, as I tend to forget things after a while but if you've read it and have another alternative, please let me know. So far the only other ways I can think of fixing it is by modifying the Jenkins core, which would require a longer time to design the change and get its approval (if approved) by core-devs.

          Bruno P. Kinoshita added a comment - Previous comment was also a memory note, as I tend to forget things after a while but if you've read it and have another alternative, please let me know. So far the only other ways I can think of fixing it is by modifying the Jenkins core, which would require a longer time to design the change and get its approval (if approved) by core-devs.

          Hello, kinow

          Started by fixing the variables jenkinsBuild and jenkinsProject for pipeline builds (which also removes one deprecated method call at least). Then created a few pipeline jobs to test the plug-in. As expected, when you add "This build is parameterized", everything works as expected.

          This doesn't match my experience — groovy.lang.Binding only has the jenkinsParameter variable for any pipeline job that I test, "This build is parameterized" option is checked on each one. Is this fix not included in the official releases yet? I'm using Active Choices plugin version 2.2.1

          Kamil Magomedov added a comment - Hello, kinow Started by fixing the variables jenkinsBuild and jenkinsProject for pipeline builds (which also removes one deprecated method call at least). Then created a few pipeline jobs to test the plug-in. As expected, when you add "This build is parameterized", everything works as expected. This doesn't match my experience — groovy.lang.Binding only has the jenkinsParameter variable for any pipeline job that I test, "This build is parameterized" option is checked on each one. Is this fix not included in the official releases yet? I'm using Active Choices plugin version 2.2.1

          Hi , once released the issue will be marked as closed or fixed here. I have no bandwidth to work on this right now, but happy to review/merge pull requests.

          Bruno

          Bruno P. Kinoshita added a comment - Hi , once released the issue will be marked as closed or fixed here. I have no bandwidth to work on this right now, but happy to review/merge pull requests. Bruno

          Ioannis Moutsatsos added a comment - - edited

          kinow thanks for the interesting comment/memory dump above! As of now (OCT-25-2019), there are at least 13 different active-choice Jira related tickets referencing the use of this plugin in pipeline jobs/Jenkinsfile. Given that this plugin was designed to be used interactively on freestyle job build forms (clearly stated in the plugin documentation) is there a point to keep looking for solutions in this space especially if there are no convenient Jenkins extension points to support this approach?  Should we just close all these issues as will not be done. It seems no-one is reading the plugin documentation any longer. Perhaps these AC shortcomings could be addressed in a different plugin designed specifically for pipeline jobs.

          Ioannis Moutsatsos added a comment - - edited kinow thanks for the interesting comment/memory dump above! As of now (OCT-25-2019), there are at least 13 different active-choice Jira related tickets referencing the use of this plugin in pipeline jobs/Jenkinsfile. Given that this plugin was designed to be used interactively on freestyle job build forms (clearly stated in the plugin documentation) is there a point to keep looking for solutions in this space especially if there are no convenient Jenkins extension points to support this approach?  Should we just close all these issues as will not be done. It seems no-one is reading the plugin documentation any longer. Perhaps these AC shortcomings could be addressed in a different plugin designed specifically for pipeline jobs.

          Moving work to JENKINS-63284. This way it will be easier for me to triage issues, and keep track of requests for pipelines (this issue will be linked).

          Bruno P. Kinoshita added a comment - Moving work to JENKINS-63284 . This way it will be easier for me to triage issues, and keep track of requests for pipelines (this issue will be linked).

            kinow Bruno P. Kinoshita
            analogj Jason Kulatunga
            Votes:
            9 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated:
              Resolved: