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

active choices reactive parameter cant load shared library

      In groovy script in parameter i havent access into Groovy shared library.

      I use version 1.5.3 of Active Choices Plugin.

      In job workflow works same include.

          [JENKINS-46394] active choices reactive parameter cant load shared library

          Ioannis Moutsatsos added a comment - - edited

          Have you tried using the grapes Groovy dependency management?

          Then in your Active Choices script you can use the @Grab annotation.

          In one of my script I'm using the Http-Builder-ng library for web service calls. In that case the Active Choices script @Grab annotation looks like this.

          Ioannis Moutsatsos added a comment - - edited Have you tried using the grapes Groovy dependency management? Then in your Active Choices script you can use the @Grab annotation. In one of my script I'm using the Http-Builder-ng library for web service calls. In that case the Active Choices script @Grab annotation looks like this.

          Sounds like a good workaround.

          Tried after following instructions from this post https://tcollignon.github.io/2017/07/10/How-To-Use-third-party-libraries-in-Jenkins-Pipeline.html (TL;DR had to install Pipeline Shared Groovy Libraries Plugin).

          Let's leave it open for a while to wait for user comments. Otherwise mark as won't fix in favour of the workaround in the next issue triaging.

          Bruno P. Kinoshita added a comment - Sounds like a good workaround. Tried after following instructions from this post https://tcollignon.github.io/2017/07/10/How-To-Use-third-party-libraries-in-Jenkins-Pipeline.html (TL;DR had to install Pipeline Shared Groovy Libraries Plugin). Let's leave it open for a while to wait for user comments. Otherwise mark as won't fix in favour of the workaround in the next issue triaging.

          I think that the possibility to centralize common function in a shared library it's more robust than insert code in each pipeline/job instead.

          Michele Vanini added a comment - I think that the possibility to centralize common function in a shared library it's more robust than insert code in each pipeline/job instead.

          I Don't think this is a suitable solution for Tomas. He probably wanted to be able to load the "Global Pipeline Libraries" from the "Groovy Script" box in the Active Choices Parameter.

          (paveto: correct me if im wrong)

          Samuel Archambault added a comment - I Don't think this is a suitable solution for Tomas. He probably wanted to be able to load the " Global Pipeline Libraries " from the "Groovy Script" box in the Active Choices Parameter. ( paveto : correct me if im wrong)

          I would prefer to use scripts from Global Pipeline Libraries instead of @Grab or Scriptler

          Viktor Bogdanov added a comment - I would prefer to use scripts from  Global Pipeline Libraries  instead of @Grab or Scriptler

          Ingmar Karge added a comment -

          I think the workaround is too inconvenient to use. I want to include my own library (which I already use in the jenkins pipeline) and not an external lib.

          Ingmar Karge added a comment - I think the workaround is too inconvenient to use. I want to include my own library (which I already use in the jenkins pipeline) and not an external lib.

          Ashwin Pai added a comment -

          I too would vote in favour of this feature. It would be very useful to have a single shared groovy lib that can be used across. 

          Ashwin Pai added a comment - I too would vote in favour of this feature. It would be very useful to have a single shared groovy lib that can be used across. 

          The same case - I need this feature !!!

          Robert GrÄ…dzki added a comment - The same case - I need this feature !!!

          Looks like this is something useful for users. Next development cycle will start looking into ways other plugins are using to support that. I really want to avoid the plugin being blacklisted again due to security issues/CVE's. So my plain is

          1. learn how other plugins are working
          2. create a branch with the solution
          3. upload here a .hpi file with the proposed solution, and also try to release to the experimental update site (not sure if that still exists)
          4. release only, and really only, if there's enough testing from users that also took into consideration possible attack vectors created by this feature (i.e. giving some thought to what issues this feature could cause... do they have a security permission model that could allow users to use dangerous libraries? did we implement in a way that the administrator him/herself could shoot his own foot and accidentally introduce a security problem in their jenkins/etc)

          And once we pass step 4, and we are confident this won't introduce a security bug, cut a release. Let me know if anyone has any other suggestions, or if interested in helping with the testing/development.

          Cheers
          Bruno

          Bruno P. Kinoshita added a comment - Looks like this is something useful for users. Next development cycle will start looking into ways other plugins are using to support that. I really want to avoid the plugin being blacklisted again due to security issues/CVE's. So my plain is 1. learn how other plugins are working 2. create a branch with the solution 3. upload here a .hpi file with the proposed solution, and also try to release to the experimental update site (not sure if that still exists) 4. release only, and really only, if there's enough testing from users that also took into consideration possible attack vectors created by this feature (i.e. giving some thought to what issues this feature could cause... do they have a security permission model that could allow users to use dangerous libraries? did we implement in a way that the administrator him/herself could shoot his own foot and accidentally introduce a security problem in their jenkins/etc) And once we pass step 4, and we are confident this won't introduce a security bug, cut a release. Let me know if anyone has any other suggestions, or if interested in helping with the testing/development. Cheers Bruno

          Robert GrÄ…dzki added a comment - - edited

          I can help with the testing.

          Robert GrÄ…dzki added a comment - - edited I can help with the testing.

          Very interested in accessing a  json file in the resources directory as defined from this facility:

          https://jenkins.io/doc/book/pipeline/shared-libraries/

          My use case is to read a json file and present part of the data in a active choice parameter.

          michael pechner added a comment - Very interested in accessing a  json file in the resources directory as defined from this facility: https://jenkins.io/doc/book/pipeline/shared-libraries/ My use case is to read a json file and present part of the data in a active choice parameter.

          We have the same situation. We would love to use Active Choice directly with our pipeline. We got it working for simple stuff using:

          properties([parameters([    [$class: 'org.biouno.unochoice.ChoiceParameter', name: 'Ambiente', choiceType: 'PT_RADIO', description: 'Escolha para qual ambiente o artefato devera ser implantado.', filterLength: 1, filterable: false, randomName: 'choice-parameter-47910233643731',        script: [            $class: 'org.biouno.unochoice.model.GroovyScript',            script:[                $class:'SecureGroovyScript',                script:'''return ["desenvolvimento:selected", "alfa", "beta", "producao"]'''            ]        ]    ]    ,[$class: 'org.biouno.unochoice.CascadeChoiceParameter', name: 'Servidores', choiceType: 'PT_CHECKBOX', description: 'Escolha o pool ou servidores alvo.', filterLength: 1, filterable: false, randomName: 'choice-parameter-51976913619136',        referencedParameters: 'Ambiente',        script: [            $class: 'org.biouno.unochoice.model.GroovyScript',            script:[                $class:'SecureGroovyScript',                script:'''if ("desenvolvimento".equals(Ambiente)) { return ["POOL-DESENV","D001", "D002", "D003", "D004"] } else if ("alfa".equals(Ambiente)) { return ["alfa:selected"] } else if ("beta".equals(Ambiente)) { return ["beta:selected"] } else if ("producao".equals(Ambiente)) { return ["producao:selected"] } else { return [] }'''            ],            fallbackScript:[                $class: 'SecureGroovyScript',                script: '''return["Erro na carga de servidores"]'''            ]        ]    ]

           
          Working groovy as a string in the pipeline is a pain. Having to authorize this script every time you change the groovy code. If you have shared library support you don't have to ever change these scripts because de shared lib will be the one changing.
           
          And then all our code will be groovy from git. Much easier to maintain. Is there a way to try an Active Choice with this feature? Or a timeline for this feature if ever.
           

          Daniel Pereira added a comment - We have the same situation. We would love to use Active Choice directly with our pipeline. We got it working for simple stuff using: properties([parameters([     [$class: 'org.biouno.unochoice.ChoiceParameter', name: 'Ambiente', choiceType: 'PT_RADIO', description: 'Escolha para qual ambiente o artefato devera ser implantado.', filterLength: 1, filterable: false, randomName: 'choice-parameter-47910233643731',         script: [             $class: 'org.biouno.unochoice.model.GroovyScript',             script:[                 $class:'SecureGroovyScript',                 script:'''return  ["desenvolvimento:selected", "alfa", "beta", "producao"] '''             ]         ]     ]     ,[$class: 'org.biouno.unochoice.CascadeChoiceParameter', name: 'Servidores', choiceType: 'PT_CHECKBOX', description: 'Escolha o pool ou servidores alvo.', filterLength: 1, filterable: false, randomName: 'choice-parameter-51976913619136',         referencedParameters: 'Ambiente',         script: [             $class: 'org.biouno.unochoice.model.GroovyScript',             script:[                 $class:'SecureGroovyScript',                 script:'''if ("desenvolvimento".equals(Ambiente)) { return  ["POOL-DESENV","D001", "D002", "D003", "D004"]  } else if ("alfa".equals(Ambiente)) { return  ["alfa:selected"]  } else if ("beta".equals(Ambiente)) { return  ["beta:selected"]  } else if ("producao".equals(Ambiente)) { return  ["producao:selected"]  } else { return [] }'''             ],             fallbackScript:[                 $class: 'SecureGroovyScript',                 script: '''return ["Erro na carga de servidores"] '''             ]         ]     ]   Working groovy as a string in the pipeline is a pain. Having to authorize this script every time you change the groovy code. If you have shared library support you don't have to ever change these scripts because de shared lib will be the one changing.   And then all our code will be groovy from git. Much easier to maintain. Is there a way to try an Active Choice with this feature? Or a timeline for this feature if ever.  

          shagun jian added a comment -

          Is this feature released? I have the same case.

          shagun jian added a comment - Is this feature released? I have the same case.

          Yuriy Burtsev added a comment -

          jainsh, no, this is not happening.

          Yuriy Burtsev added a comment - jainsh , no, this is not happening.

          shagun jian added a comment -

           this could have been a great feature. 

          shagun jian added a comment -  this could have been a great feature. 

          Paul Thevenot added a comment -

          Same case here. This would be a nice feature. 

          Paul Thevenot added a comment - Same case here. This would be a nice feature. 

          I agree, and really would like to implement it. But first would need to find either some good guidelines to avoid security issues later, or have a good amount of time to investigate possible solutions. The risk with this feature is that the plugin would be blacklisted (again) due to security issues in the implementation.

          Bruno P. Kinoshita added a comment - I agree, and really would like to implement it. But first would need to find either some good guidelines to avoid security issues later, or have a good amount of time to investigate possible solutions. The risk with this feature is that the plugin would be blacklisted (again) due to security issues in the implementation.

          If anyone knows of a plugin doing something similar, that'd be helpful. Pull requests welcome as well

          Bruno P. Kinoshita added a comment - If anyone knows of a plugin doing something similar, that'd be helpful. Pull requests welcome as well

          Any movement on this? This would be immensely helpful

          Steven Calhoun added a comment - Any movement on this? This would be immensely helpful

          None yet stevenacalhoun, sorry. The main blocker for me is i) other pending issues and, ii) I know I will need to spend some time investigating the following:

          • How can this be safely implemented?
          • Has any other plug-ins done it in a way that didn't result in an CVE and being blacklisted by the Jenkins Security team?
          • What would we need to tell users besides this new feature? (e.g. limitations, risks, etc)

          If anyone has time to do this investigation, then I could simply go with the best approach (if any), and/or confirm with the Jenkins Security team what they think about our decision.

          From memory, I had a solution from another plug-in (hmmm, ext-parameter? extended-parameter-choice? Some name like this), but got a message on IRC or in another media from core devs about the risks of this approach. Then, shortly after, we got blacklisted for other security issues, and the plug-in was unavailable for some weeks (can't recall if it completed 1 or 2 months of suspension until we sorted the CVE and released the fix).

          Hence my caution in implementing this feature (which I find very useful too for users).

          Bruno P. Kinoshita added a comment - None yet stevenacalhoun , sorry. The main blocker for me is i) other pending issues and, ii) I know I will need to spend some time investigating the following: How can this be safely implemented? Has any other plug-ins done it in a way that didn't result in an CVE and being blacklisted by the Jenkins Security team? What would we need to tell users besides this new feature? (e.g. limitations, risks, etc) If anyone has time to do this investigation, then I could simply go with the best approach (if any), and/or confirm with the Jenkins Security team what they think about our decision. From memory, I had a solution from another plug-in (hmmm, ext-parameter? extended-parameter-choice? Some name like this), but got a message on IRC or in another media from core devs about the risks of this approach. Then, shortly after, we got blacklisted for other security issues, and the plug-in was unavailable for some weeks (can't recall if it completed 1 or 2 months of suspension until we sorted the CVE and released the fix). Hence my caution in implementing this feature (which I find very useful too for users).

          This will be very very .... very useful for us as well .

          Limor Segal Shevah added a comment - This will be very very .... very useful for us as well  .

          Still useful!

          Valeriy Zabawski added a comment - Still useful!

          Filat added a comment -

          Need this feature!

          Filat added a comment - Need this feature!

          Ioannis Moutsatsos added a comment - - edited

          I don't use pipeline or shared libraries in my builds and so I can't comment directly. But I do write and reuse a lot of Groovy scripts using the [scriptler plugin|jenkinsci/scriptler-plugin: Jenkins scriptler plugin (github.com)] I think the safest approach is to use Scriptler for Active Choice Parameters and Shared Libraries for scripts required in the pipeline. Scriptler and shared libraries both support the same reuse goals and can be managed centrally

          By the way the '@Grab' strategy mentioned earlier, no longer works and is blocked in more recent versions of Jenkins. 3rd party libraries (jars) can be used using a workaround when starting Jenkins so that the external jars are in the Jenkins classpath.

          Ioannis Moutsatsos added a comment - - edited I don't use pipeline or shared libraries in my builds and so I can't comment directly. But I do write and reuse a lot of Groovy scripts using the [scriptler plugin| jenkinsci/scriptler-plugin: Jenkins scriptler plugin (github.com) ] I think the safest approach is to use Scriptler for Active Choice Parameters and Shared Libraries for scripts required in the pipeline. Scriptler and shared libraries both support the same reuse goals and can be managed centrally By the way the '@Grab' strategy mentioned earlier, no longer works and is blocked in more recent versions of Jenkins . 3rd party libraries (jars) can be used using a workaround when starting Jenkins so that the external jars are in the Jenkins classpath.

          Filat added a comment -

          ioannis 
          Unfortunately, the scriptler has a bad effect on jcasc. He can abort the entire production update when he doesn't like some script. So I'm looking for a way to get away from the scriptler. it is also convenient to store gsl in scm. Although the scriptler uses git to version scripts, it does not support pulling updates from remote repositories.

          Filat added a comment - ioannis   Unfortunately, the scriptler has a bad effect on jcasc. He can abort the entire production update when he doesn't like some script. So I'm looking for a way to get away from the scriptler. it is also convenient to store gsl in scm. Although the scriptler uses git to version scripts, it does not support pulling updates from remote repositories.

            kinow Bruno P. Kinoshita
            paveto Tomas Pavelka
            Votes:
            37 Vote for this issue
            Watchers:
            45 Start watching this issue

              Created:
              Updated: