That's correct - we're using Job DSL to create pipeline jobs.
It allows you to set your pipeline job definition as well as the script
portion as part of the same Groovy script using a builder pattern.
The visual editor in Blue Ocean, as far as I know, does not meet our goals
for the main reason that we set up all of our jobs using DSL. In addition,
as part of our DSL libraries we like to set up different utilities that
lead to more consistent pipeline jobs across our different projects/users.
I believe the visual editor would not help us achieve this goal.
Here's another simplified example of how you would you this script builder,
compared to what it would look like without it.
Without it:
pipelineJob('example'){
definition {
cps{
script("""pipeline {
agent none
stages {
stage('Stage 1') {
stage('Build Stage') {
agent {
node {
label 'windowsBuilderServer'
}
}
steps {
checkout([$class: 'GitSCM', branches: [[name: env.ghprbActualCommit]],
browser: [$class: 'GithubWeb', repoUrl: "XX"],
doGenerateSubmoduleConfigurations: false, poll: false, extensions: [],
submoduleCfg: [], userRemoteConfigs: [[credentialsId: "YY", url:
"XX.git"]]])
stash includes:"ProjectName/**/*", name:"stash1"
}
post {
always {
deleteDir()
}
}
}
}
stage('Stage 2') {
parallel {
stage('Parallel 1') {
agent {
node {
label 'linuxBuildServer'
}
}
steps {
deleteDir()
unstash name:"stash1"
sh """some script"""
}
post {
success {
deleteDir()
}
always {
archiveArtifacts artifacts:"*.e*,*.o*", excludes:"",
allowEmptyArchive:true, fingerprint:true, onlyIfSuccessful:false
junit allowEmptyResults: true, testDataPublishers: [[$class:
'AttachmentPublisher'], [$class: 'StabilityTestDataPublisher']],
testResults: 'test_results/*.xml'
}
}
}
}
}
}
}
""")
sandbox()
}
}
And using the script builder: **Contains a couple of our internal helper
methods but they don't have anything fancy
Stage stage1 = Stage.create('Stage 1')
.setAgent(Agent.fromExecutor(Executor.WINDOWS))
.addStep(checkoutFromGit('XX', 'env.ghprbActualCommit'))
.addStep(stash('stash1', 'ProjectName/**/*'))
.addPost(Post.Condition.ALWAYS, deleteDir())
ParallelStage stage2 = ParallelStage.create('Stage 2')
//datasetList is a List<String> such that each string is a data set name
//The following will create a prallel stage for each list element
datasetList.collect {
Stage.create(it)
.setAgent(Agent.fromExecutor(Executor.LINUX))
.addStep(deleteDir())
.addStep(unstash('stash1'))
.addStep(sh("""some script"""))
.addPost(Post.Condition.SUCCESS, deleteDir())
.addPost(Post.Condition.ALWAYS,
archiveArtifacts('*.e*,*.o*','',true, true,false))
.addPost(Post.Condition.ALWAYS,
publishJUnitXml('test_results/*.xml', true))
}.each { stage2 = stage2.addStage(it) }
def script = PipelineScript.create()
.addStage(stage1)
.addParallelStage(stage2)
pipelineJob('example'){
definition {
cps{
script(script)
sandbox()
}
}
As you can see you could set up the entire job in a single block (as shown
in my first post) or break the definitions to multiple variables for more
complex logic.
I simplified most of the above example since it heavily depends on our
utilities libraries but hopefully it is sufficiently clear.
This library has been widely used in our team and received positive
feedback so I thought it would be useful to share with the community. It is
definitely not the only way of doing things but we found it to be pretty
useful.
Sharon
On Thursday, January 4, 2018 at 3:13:15 PM UTC-8, Liam Newman wrote:
>
> Sharon,
>
> From context, it sounds like you're using the Job DSL to create Pipeline
> jobs. Is that correct?
> Could you share an example of what your code would have to look like
> without your tool?
>
> Thanks,
> -Liam Newman
>
>
>
>
>
>
>
>
> On Wed, Jan 3, 2018 at 2:09 PM Jesse Glick <[email protected]
> <javascript:>> wrote:
>
>> On Wed, Jan 3, 2018 at 1:50 PM, Sharon Grubner <[email protected]
>> <javascript:>> wrote:
>> > requires all users to know the
>> > declarative pipeline syntax
>>
>> Why not just use the Declarative visual editor in Blue Ocean, for
>> users unfamiliar with the syntax?
>>
>> > does not allow sharing common functions and
>> > practices.
>>
>> You can use Groovy libraries from Declarative, with certain restrictions.
>>
>> I am not sure I see the point here. If you want to expose a
>> programmatic interface to users, then why are you using Declarative at
>> all? You can publish libraries for use from Scripted which offer
>> reusable functional chunks of all kinds already (including
>> “higher-order” functions such as control operators), and this would be
>> much more direct as your script would be the Groovy that actually
>> runs, rather than a builder that creates a script that is interpreted
>> by Declarative to create something to run. Maybe I am just not
>> following what your tool actually does.
>>
>> --
>> 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] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1_KFxTjnEiddcwZv%3D7jndJvgX%2BgRp%3DUL5DeB5bmx%2B7%3Dg%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/440933c0-8a04-4344-8617-2d136453e937%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
