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

          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: