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

Active Choices plugin doesn't work with Workflow Plugin

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            kinow 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.

             

            Show
            kinow 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.  
            Hide
            kinow 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.

            Show
            kinow 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.
            Hide
            kmagomedov Kamil Magomedov added a comment -

            Hello, Bruno P. Kinoshita

            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

            Show
            kmagomedov Kamil Magomedov added a comment - Hello, Bruno P. Kinoshita 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
            Hide
            kinow 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

            Show
            kinow 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

              People

              • Assignee:
                kinow Bruno P. Kinoshita
                Reporter:
                analogj Jason Kulatunga
              • Votes:
                9 Vote for this issue
                Watchers:
                19 Start watching this issue

                Dates

                • Created:
                  Updated: