On Wed, Jun 4, 2014 at 2:56 PM, Kohsuke Kawaguchi <[email protected]> wrote: > you have a short DSL > in the job definition whose sole purpose is to call SCM step to get the code > checked out, then load the real DSL script from the checked out copy.
The main concern here (which would apply equally to an SCM-based FlowDefinition) is script security. For sandboxed scripts it is probably not an issue since the “source this file” primitive would presumably run the file it loaded through the sandbox as well. But you could not (soundly) approve the whole script, because you would not know what you were approving. Anyway I think this is not a high priority. What you normally want to change in an SCM branch is your build script (pom.xml, build.xml, Makefile, etc.) that has detailed knowledge of the layout and meaning of sources. The workflow script is generally going to delegate to one or more build scripts, and be concerned with Jenkins specifics such as slave allocation, interactive pauses, and the like. While some of these behaviors might be specific to a feature or release branch, more commonly I think they would apply equally to any reasonably recent version of your code. The main exception I can think of would be a list of artifacts to archive, which is something that might change frequently in sources, unless you just designate a particular ‘dist’ directory to hold everything you want to save. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
