-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Powered by SuggestiMate
activeChoice supports placing scripts in the sandbox, which removes the requirement to have a admin approve the script.
It would be great if job-dsl could support setting the sandbox.
Currently its getting set to the default value, false.
- screenshot-1.png
- 197 kB
- screenshot-2.png
- 126 kB
- is duplicated by
-
JENKINS-42710 Update Active Choices DSL to support new secureScript tag (script-security-plugin)
-
- Closed
-
[JENKINS-41308] support Use Groovy Sandbox scripts in activeChoiceParams
It is possible to use Dynamic DSL. Unfortunately, it has two disadvantages:
- it forces to set all parameters, even those which we don't want to set (the default values are fine for us). This behavior is also a cause that the code could stop working after the 3rd-party plugin update (for example a new field has been added)
- the code which does simple stuff is much longer and less readable
Examples:
- Dynamic DSL:
choiceParameter { delegate.name(name) delegate.description(description) delegate.choiceType('PT_RADIO') delegate.script { groovyScript { script { script(valuesToString()) sandbox(true) } fallbackScript{ script('') sandbox(true) } } } delegate.randomName('') delegate.filterable(false) delegate.filterLength(0) }
- Static DSL:
activeChoiceParam(name) { delegate.description(this.description) delegate.choiceType('RADIO') delegate.groovyScript { script(valuesToString()) { sandbox() } } }
As a user I would be really happy to have this feature merged.
From the other side, if you don't want to merge anything related to static DSL, it would be good if you could mark it as deprecated. Keeping it in the current state confuses the users. They use and even create PRs to the code which is frozen (never will be changed - according to the statement that all PRs are declined).
All comments
tknerr You must use the choiceParameter instead of activeChoiceParam. choiceParameter is provided by the Automatically Generated DSL, activeChoiceParam is the built-in DSL.
daspilker nevermind, I found it. Did not notice that the generated parameter is named differently ("choiceParameter"):
Your example from above is working (in that it generates a valid config.xml at least) and gets me a big step further.
Thanks a lot!
Using automatically generated DSL is a workaround, not a fix. We need real / direct support for enabling sandboxing.
If I try to use automatically generated DSL, then "mvn test" in my dsl source fails, and the only examples of tests of automatically-generated DSL use gradle, not maven.
I had the same issues using tknerr dsl script above with active choice and active reactive parameters.
The below worked work me though
configure { project -> def scriptContainers = project / 'properties' / 'hudson.model.ParametersDefinitionProperty' / 'parameterDefinitions' scriptContainers.each { org_level -> // wrap <script> inside a <secureScript> def script_level = org_level / 'script' script_level.appendNode('secureScript', [plugin: 'script-security@1.34']).with { appendNode('sandbox', 'true') appendNode('script', script_level.script.text()) script_level.remove(script_level / 'script') } script_level.appendNode('secureFallbackScript', [plugin: 'script-security@1.34']).with { appendNode('sandbox', 'true') appendNode('script',script_level.fallbackScript.text()) script_level.remove(script_level / 'fallbackScript') } } }
To fix this issue, I created a PR (https://github.com/jenkinsci/job-dsl-plugin/pull/1211) with a green build (https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fjob-dsl-plugin/detail/PR-1211/1/pipeline/). All the old functionality stays unchanged and only the `sandbox` option was added in. There are tests, documentation and the contribution guidelines have been followed.
Please have a look and let me know if any changes need to be made before this can be integrated.
Please have a look at the PR
Is there any way we can expedite the PR merge? The workaround with configure block works, but it introduces performance implication (with configure block, DSL plugin re-formats config XML with every run and restores some optional elements and attributes).
Please use Dynamic DSL or a configure block if Dynamic DSL is not available in your environment. I'm no longer accepting changes for options that are available in Dynamic DSL.
It is actually not fully supported by Dynamic DSL and causes problems like not showing up or not being able to be used due to conflicts. The Pull Request works, there is obviously a real need for this fix (see all the people having issues with Dynamic DSL and the ugliness of the Configure block (causing other problems for example with other plugins).
Existing functionality and tests are unchanged with the PR.
What is the real reason this is being closed?
It is possible to use Dynamic DSL. Unfortunately, it has two disadvantages:
- it forces to set all parameters, even those which we don't want to set (the default values are fine for us). This behavior is also a cause that the code could stop working after the 3rd-party plugin update (for example a new field has been added)
- the code which does simple stuff is much longer and less readable
Examples:
- Dynamic DSL:
choiceParameter { delegate.name(name) delegate.description(description) delegate.choiceType('PT_RADIO') delegate.script { groovyScript { script { script(valuesToString()) sandbox(true) } fallbackScript{ script('') sandbox(true) } } } delegate.randomName('') delegate.filterable(false) delegate.filterLength(0) }
- Static DSL:
activeChoiceParam(name) { delegate.description(this.description) delegate.choiceType('RADIO') delegate.groovyScript { script(valuesToString()) { sandbox() } } }
As a user I would be really happy to have this feature merged.
From the other side, if you don't want to merge anything related to static DSL, it would be good if you could mark it as deprecated. Keeping it in the current state confuses the users. They use and even create PRs to the code which is frozen (never will be changed - according to the statement that all PRs are declined).
daspilker oh that is possible?
It wasn't showing up on my local instances embedded API viewer, so I thought the automatically generated DSL would not be available. How can I tell if it is?