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

          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: