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

support Use Groovy Sandbox scripts in activeChoiceParams

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • job-dsl-plugin
    • None

      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.

          [JENKINS-41308] support Use Groovy Sandbox scripts in activeChoiceParams

          Pinned comments

          Pinned by Eva Müller

          Adam Gabryś added a comment -

          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).

          Adam Gabryś added a comment - 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

          Torben Knerr added a comment -

          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?

          Torben Knerr added a comment - 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?

          tknerr You must use the choiceParameter instead of activeChoiceParam. choiceParameter is provided by the Automatically Generated DSL, activeChoiceParam is the built-in DSL.

          Daniel Spilker added a comment - tknerr You must use the choiceParameter instead of activeChoiceParam . choiceParameter is provided by the Automatically Generated DSL, activeChoiceParam is the built-in DSL.

          Torben Knerr added a comment -

          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!

          Torben Knerr added a comment - 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!

          Dana Goyette added a comment -

          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.

          Dana Goyette added a comment - 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.

          Benson Ngoy added a comment -

          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')
                    } 
                    
                  }
              }

           

          Benson Ngoy added a comment - 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' ) } } }  

          Daniel Steiert added a comment - - edited

          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

          Daniel Steiert added a comment - - edited 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

          Michael Tupitsyn added a comment - - edited

          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).

          Michael Tupitsyn added a comment - - edited 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.

          Daniel Spilker added a comment - 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?

          Daniel Steiert added a comment - 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?

          Pinned by Eva Müller

          Adam Gabryś added a comment -

          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).

          Adam Gabryś added a comment - 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 Daniel Spilker
            glance Anton Lundin
            Votes:
            3 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: