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

active choices reactive parameter cant load shared library

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Activity

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

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

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

          Show
          mvanini 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.
          Hide
          samifruit514 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.

          (Tomas Pavelka: correct me if im wrong)

          Show
          samifruit514 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. ( Tomas Pavelka : correct me if im wrong)
          Hide
          agsmith Viktor Bogdanov added a comment -

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

          Show
          agsmith Viktor Bogdanov added a comment - I would prefer to use scripts from  Global Pipeline Libraries  instead of @Grab or Scriptler
          Hide
          igge 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.

          Show
          igge 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.
          Hide
          ashwinpai1981 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. 

          Show
          ashwinpai1981 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. 
          Hide
          roercik Robert Grądzki added a comment -

          The same case - I need this feature !!!

          Show
          roercik Robert Grądzki added a comment - The same case - I need this feature !!!
          Hide
          kinow 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

          Show
          kinow 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
          Hide
          roercik Robert Grądzki added a comment - - edited

          I can help with the testing.

          Show
          roercik Robert Grądzki added a comment - - edited I can help with the testing.
          Hide
          mpechner 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.

          Show
          mpechner 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.
          Hide
          envolva 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.
           

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

            People

            • Assignee:
              kinow Bruno P. Kinoshita
              Reporter:
              paveto Tomas Pavelka
            • Votes:
              16 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

              • Created:
                Updated: