| 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. |
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.