Christian Höltje added a comment - 2017-03-10 22:07 Use case: Joe creates a GitHub Org Folder.  His repos foo and bar are scanned and picked up because they have a Jenkinsfile in each. foo is a huge repository (2gb) and he only wants the last 10 commits when building (a shallow clone with depth 10) and without any tags. bar  uses lots of submodules, but isn't big.  He wants the submodule extensions turned on and to use the GitHub Org credentials. This could be done by allow adding extensions at the GitHub Org Folder level, but that would mean forcing all builds to have a depth of 10, no tags, and submodules turned on.  This could cause people to split the GitHub Orgs up just to accommodate Jenkins (which may not be possible, if they are paying for the Orgs, etc.) An idea is we could change the scm from an Object to the list form (I don't know what it is called) that looks like [$class:GitSCM, extensions: ... ] I have some code I run in a trusted pipeline via the src/ directory that almost  does this...   class ScmEditablizer { static def makeScmEditable(scm, env) { Integer i def branches = [] for (i = 0; i < scm.branches.size(); i++) { def it = scm.branches.get(i) branches.add([name: it.getName()]) } def userRemoteConfigs = [] for (i = 0; i < scm.userRemoteConfigs.size(); i++) { def it = scm.userRemoteConfigs.get(i) userRemoteConfigs.add([ name: it.getName(), url: it.getUrl(), credentialsId: it.getCredentialsId(), refspec: it.getRefspec() ]) } return [ $class: 'GitSCM' , extensions: [], branches: branches, userRemoteConfigs: userRemoteConfigs ] } } But this doesn't work because the extensions are missing and it doesn't understand Pull Requests (I don't know why exactly). This allows getting an "editable" scm object that can have extensions, etc. added to it.  

Michael Neale added a comment - 2017-03-14 01:40 Is the aim here to "kill job DSL"?    "have a simple way of calling into scm-api implementations from a Job DSL folder" - interesting use of "simple". I would say "for very advanced users".