-
Bug
-
Resolution: Unresolved
-
Major
-
Powered by SuggestiMate
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
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.
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
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.
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.
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
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.
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
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).
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
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.
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.