Job DSL Command Line Tool
466 views
Skip to first unread message
Daniel Spilker
Jan 2, 2015, 9:31:16 AM1/2/15
to job-dsl...@googlegroups.com
Is anyone using the Job DSL command line tool?
I want to deprecate the command line tool and remove it in a future version because of several reasons:
* Use cases for the command line tool are testing a Job DSL snippet, which can also be done ad-hoc on the playground or with unit tests as shown in the job-dsl-gradle-example.
* Several new Job DSL features like generating XML depending on the installed plugin version or looking up credential IDs or config file IDs are not available in the command line tool.
* There are no tests for the command line tool and I'm not testing it manually before cutting a release, so it may already be broken or break any time.
The Job DSL uses a JobManagement interface for interacting with backend implementations. Currently there are three implementations. JenkinsJobManagement is used when running the plugin as build step in Jenkins, FileJobManagement is used for the command line tool and StringJobManagement is used for internal testing. As outlined above I want to get rid of FileJobManagement. StringJobManagement on the otherhand could be useful for the playground and for unit testing. There has been a pull request to publish the JAR with the test classes to make StringJobManagement available to third-parties. Instead of publishing the test files, I want to promote StringJobManagement to the production classes and add proper tests. Then it can replace the mock implementations for the playground and for unittests.
What do you think?
Daniel
I want to deprecate the command line tool and remove it in a future version because of several reasons:
* Use cases for the command line tool are testing a Job DSL snippet, which can also be done ad-hoc on the playground or with unit tests as shown in the job-dsl-gradle-example.
* Several new Job DSL features like generating XML depending on the installed plugin version or looking up credential IDs or config file IDs are not available in the command line tool.
* There are no tests for the command line tool and I'm not testing it manually before cutting a release, so it may already be broken or break any time.
The Job DSL uses a JobManagement interface for interacting with backend implementations. Currently there are three implementations. JenkinsJobManagement is used when running the plugin as build step in Jenkins, FileJobManagement is used for the command line tool and StringJobManagement is used for internal testing. As outlined above I want to get rid of FileJobManagement. StringJobManagement on the otherhand could be useful for the playground and for unit testing. There has been a pull request to publish the JAR with the test classes to make StringJobManagement available to third-parties. Instead of publishing the test files, I want to promote StringJobManagement to the production classes and add proper tests. Then it can replace the mock implementations for the playground and for unittests.
What do you think?
Daniel
Patrick van Dissel
Jan 2, 2015, 11:41:47 AM1/2/15
to job-dsl...@googlegroups.com
Hey Daniel,
I'm not using the cli tool, but I am using the FileJobManagement in my
Gradle Jenkins JobDSL plugin:
- https://github.com/pvdissel/gradle-jenkins-jobdsl
-
https://github.com/pvdissel/gradle-jenkins-jobdsl/blob/master/plugin/src/main/groovy/nl/ikoodi/gradle/plugin/jenkins/jobdsl/GradleFileJobManagement.groovy
extends FileJobManagement
With this plugin, we generate the XML files during development. This way
we can compare the generated XML with what we expect to be generated,
which is for example configured in a local test jenkins instance.
You can get an idea of the usage in the following talk I gave:
- https://github.com/pvdissel/talk-jenkins-jobdsl
https://www.youtube.com/watch?v=8jQm2wqX4xc
Ofcourse the FileJobManagement class isn't really exciting, so if you
remove it, I'm also fine. I'll just implement it in my plugin then.
/Patrick
On 01/02/2015 03:30 PM, Daniel Spilker wrote:
> Is anyone using the Job DSL command <
> https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#run-a-dsl-script-locally>
> line
> <https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#generate-a-job-configxml-without-having-to-fire-up-jenkins>
> job-dsl-gradle-example
> <https://github.com/daspilker/job-dsl-gradle-example>.
> You received this message because you are subscribed to the Google
> Groups "job-dsl-plugin" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to job-dsl-plugi...@googlegroups.com
> <mailto:job-dsl-plugi...@googlegroups.com>.
> To post to this group, send email to job-dsl...@googlegroups.com
> <mailto:job-dsl...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32B_tECop1Bj-mE2n6aVMN70vHqC5SRkucLGpRg6kUFp3w%40mail.gmail.com
> <https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32B_tECop1Bj-mE2n6aVMN70vHqC5SRkucLGpRg6kUFp3w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
I'm not using the cli tool, but I am using the FileJobManagement in my
Gradle Jenkins JobDSL plugin:
- https://github.com/pvdissel/gradle-jenkins-jobdsl
-
https://github.com/pvdissel/gradle-jenkins-jobdsl/blob/master/plugin/src/main/groovy/nl/ikoodi/gradle/plugin/jenkins/jobdsl/GradleFileJobManagement.groovy
extends FileJobManagement
With this plugin, we generate the XML files during development. This way
we can compare the generated XML with what we expect to be generated,
which is for example configured in a local test jenkins instance.
You can get an idea of the usage in the following talk I gave:
- https://github.com/pvdissel/talk-jenkins-jobdsl
https://www.youtube.com/watch?v=8jQm2wqX4xc
Ofcourse the FileJobManagement class isn't really exciting, so if you
remove it, I'm also fine. I'll just implement it in my plugin then.
/Patrick
On 01/02/2015 03:30 PM, Daniel Spilker wrote:
> Is anyone using the Job DSL command <
> line
> <https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#generate-a-job-configxml-without-having-to-fire-up-jenkins>
> tool?
>
> I want to deprecate the command line tool and remove it in a future
> version because of several reasons:
> * Use cases for the command line tool are testing a Job DSL snippet,
> which can also be done ad-hoc on the playground
> <http://job-dsl.herokuapp.com/> or with unit tests as shown in the
>
> I want to deprecate the command line tool and remove it in a future
> version because of several reasons:
> * Use cases for the command line tool are testing a Job DSL snippet,
> which can also be done ad-hoc on the playground
> job-dsl-gradle-example
> <https://github.com/daspilker/job-dsl-gradle-example>.
> * Several new Job DSL features like generating XML depending on the
> installed plugin version or looking up credential IDs or config file IDs
> are not available in the command line tool.
> * There are no tests for the command line tool and I'm not testing it
> manually before cutting a release, so it may already be broken or break
> any time.
>
> The Job DSL uses a JobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/JobManagement.groovy>
> installed plugin version or looking up credential IDs or config file IDs
> are not available in the command line tool.
> * There are no tests for the command line tool and I'm not testing it
> manually before cutting a release, so it may already be broken or break
> any time.
>
> The Job DSL uses a JobManagement
> interface for interacting with backend implementations. Currently there
> are three implementations. JenkinsJobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-plugin/src/main/groovy/javaposse/jobdsl/plugin/JenkinsJobManagement.java>
> are three implementations. JenkinsJobManagement
> is used when running the plugin as build step in Jenkins,
> FileJobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/FileJobManagement.groovy>
> FileJobManagement
> is used for the command line tool and StringJobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/test/groovy/javaposse/jobdsl/dsl/StringJobManagement.groovy>
> is used for internal testing. As outlined above I want to get rid of
> FileJobManagement. StringJobManagement on the otherhand could be useful
> for the playground and for unit testing. There has been a pull request
> <https://github.com/jenkinsci/job-dsl-plugin/pull/282> to publish the
> FileJobManagement. StringJobManagement on the otherhand could be useful
> for the playground and for unit testing. There has been a pull request
> JAR with the test classes to make StringJobManagement available to
> third-parties. Instead of publishing the test files, I want to promote
> StringJobManagement to the production classes and add proper tests. Then
> it can replace the mock implementations for the playground and for
> unittests.
>
> What do you think?
>
> Daniel
>
> --
> third-parties. Instead of publishing the test files, I want to promote
> StringJobManagement to the production classes and add proper tests. Then
> it can replace the mock implementations for the playground and for
> unittests.
>
> What do you think?
>
> Daniel
>
> You received this message because you are subscribed to the Google
> Groups "job-dsl-plugin" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to job-dsl-plugi...@googlegroups.com
> <mailto:job-dsl-plugi...@googlegroups.com>.
> To post to this group, send email to job-dsl...@googlegroups.com
> <mailto:job-dsl...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32B_tECop1Bj-mE2n6aVMN70vHqC5SRkucLGpRg6kUFp3w%40mail.gmail.com
> <https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32B_tECop1Bj-mE2n6aVMN70vHqC5SRkucLGpRg6kUFp3w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
Stefan Wolf
Jan 2, 2015, 5:45:41 PM1/2/15
to job-dsl...@googlegroups.com
We are not using the command line tool but the FileJobManagement for tests. We have the reference xmls checked in and compare them with the generated ones. I think (I can check on Wednesday) that we use a subclass of FileJobManagement which suits our needs better. If we have to copy the current state of FileJobManagement and then keep on developing it on our side, that would be no problem, hence I would share Patrick's opinion.
Regards,
Stefan
Daniel Spilker
Jan 3, 2015, 7:57:53 AM1/3/15
to job-dsl...@googlegroups.com
We can keep FileJobManagement if it's useful. In that case I will just deprecate the Run class which contains the main method. But I need to
understand why FileJobManagement is useful, which features it needs and why it can't be replaced by StringJobmanagement. E.g. do we need the rename feature from #327? The changes in Patricks subclass seem useful and should be integrated.
--
You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/aa118882-c323-4b5c-a406-c6080d891e3f%40googlegroups.com.
Stefan Wolf
Jan 4, 2015, 6:13:55 PM1/4/15
to job-dsl...@googlegroups.com
We currently have about 6000 LOC for creating our Job Configuration. One automated test is to generate the xml-Files via FileJobManagement and then compare them to reference xmls which are checked in. So if you change something for the jobs you also will need to change the reference xmls. By doing this you see the changes each commit caused by looking at the SCM-history.
All this is especially useful for refactorings when you expect the xmls to stay the same. Something similar can probably be done by StringJobManagment. Rename is not an issue at all, so this doesn't have to be integrated.
Patrick van Dissel
Jan 5, 2015, 9:37:25 AM1/5/15
to job-dsl...@googlegroups.com
For quick comparison we look at the XMLs manually.
Our development workflow is:
- In a test jenkins, make the job change you want
- Start with some tests
- Then implement the change in the job configuration with the JobDSL
- Then run the configuration locally via with the gradle-jenkins-jobdsl,
which uses the FileJobManagement class to write the XML files to
build/jobdsl/generated/*
- Look at the generated XML and verify it looks like the XML on the test
jenkins
- If ok, then write or add additional tests
Our users workflow:
We've written a small framework which abstracts away the JobDSL for our
end-users. They simply have to apply their config in a json file
(appsconfig), and with that config we generate the whole pipelines
according to the current company standard.
You can find an older version of this framework at:
-
https://github.com/pvdissel/talk-jenkins-jobdsl/tree/master/demos/03-ci%2B%2B-setup
After the user changed their appconfig, they often look at the generated
XML, just to get an idea of if their appconfig was correct. We have some
checks build-in the framework, and it's getting stricter, but it's not
100% failsafe
/Patrick
On 01/05/2015 12:13 AM, Stefan Wolf wrote:
> We currently have about 6000 LOC for creating our Job Configuration. One
> automated test is to generate the xml-Files via FileJobManagement and
> then compare them to reference xmls which are checked in. So if you
> change something for the jobs you also will need to change the reference
> xmls. By doing this you see the changes each commit caused by looking at
> the SCM-history.
> All this is especially useful for refactorings when you expect the xmls
> to stay the same. Something similar can probably be done by
> StringJobManagment. Rename is not an issue at all, so this doesn't have
> to be integrated.
>
> Am Samstag, 3. Januar 2015 13:57:53 UTC+1 schrieb Daniel Spilker:
>
> We can keep FileJobManagement if it's useful. In that case I will
> just deprecate the Run
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/Run.groovy>
> in the job-dsl-gradle-example
> <https://github.com/daspilker/job-dsl-gradle-example>.
> <https://groups.google.com/d/optout>.
> <https://groups.google.com/d/msgid/job-dsl-plugin/7795382f-8b14-49ea-9f23-3146e07a4292%40googlegroups.com?utm_medium=email&utm_source=footer>.
Our development workflow is:
- In a test jenkins, make the job change you want
- Start with some tests
- Then implement the change in the job configuration with the JobDSL
- Then run the configuration locally via with the gradle-jenkins-jobdsl,
which uses the FileJobManagement class to write the XML files to
build/jobdsl/generated/*
- Look at the generated XML and verify it looks like the XML on the test
jenkins
- If ok, then write or add additional tests
Our users workflow:
We've written a small framework which abstracts away the JobDSL for our
end-users. They simply have to apply their config in a json file
(appsconfig), and with that config we generate the whole pipelines
according to the current company standard.
You can find an older version of this framework at:
-
https://github.com/pvdissel/talk-jenkins-jobdsl/tree/master/demos/03-ci%2B%2B-setup
After the user changed their appconfig, they often look at the generated
XML, just to get an idea of if their appconfig was correct. We have some
checks build-in the framework, and it's getting stricter, but it's not
100% failsafe
/Patrick
On 01/05/2015 12:13 AM, Stefan Wolf wrote:
> We currently have about 6000 LOC for creating our Job Configuration. One
> automated test is to generate the xml-Files via FileJobManagement and
> then compare them to reference xmls which are checked in. So if you
> change something for the jobs you also will need to change the reference
> xmls. By doing this you see the changes each commit caused by looking at
> the SCM-history.
> All this is especially useful for refactorings when you expect the xmls
> to stay the same. Something similar can probably be done by
> StringJobManagment. Rename is not an issue at all, so this doesn't have
> to be integrated.
>
> Am Samstag, 3. Januar 2015 13:57:53 UTC+1 schrieb Daniel Spilker:
>
> We can keep FileJobManagement if it's useful. In that case I will
> just deprecate the Run
> class which contains the main method. But I need to understand why
> FileJobManagement is useful, which features it needs and why it
> can't be replaced by StringJobmanagement. E.g. do we need the rename
> feature from #327
> <https://github.com/jenkinsci/job-dsl-plugin/pull/327>? The changes
> FileJobManagement is useful, which features it needs and why it
> can't be replaced by StringJobmanagement. E.g. do we need the rename
> feature from #327
> in Patricks subclass seem useful and should be integrated.
>
> @Patrick and @Stefan: I'm not sure if I understand your workflow.
> You use FileJobManagement to write the XMLs to the file system and
> then in some test case you read them in and compare them with
> another file? You could switch to StringJobManagement when that is
> available in the JAR and you don't need to write the XML and read it
> back in. Or do you compare the XML manually?!?
>
> Daniel
>
> On Fri, Jan 2, 2015 at 11:45 PM, Stefan Wolf <glow...@gmail.com
> <javascript:>> wrote:
>
> We are not using the command line tool but the FileJobManagement
> for tests. We have the reference xmls checked in and compare
> them with the generated ones. I think (I can check on Wednesday)
> that we use a subclass of FileJobManagement which suits our
> needs better. If we have to copy the current state of
> FileJobManagement and then keep on developing it on our side,
> that would be no problem, hence I would share Patrick's opinion.
>
> Regards,
> Stefan
>
> Am Freitag, 2. Januar 2015 15:31:16 UTC+1 schrieb Daniel Spilker:
>
> Is anyone using the Job DSL command
>
> @Patrick and @Stefan: I'm not sure if I understand your workflow.
> You use FileJobManagement to write the XMLs to the file system and
> then in some test case you read them in and compare them with
> another file? You could switch to StringJobManagement when that is
> available in the JAR and you don't need to write the XML and read it
> back in. Or do you compare the XML manually?!?
>
> Daniel
>
> On Fri, Jan 2, 2015 at 11:45 PM, Stefan Wolf <glow...@gmail.com
> <javascript:>> wrote:
>
> We are not using the command line tool but the FileJobManagement
> for tests. We have the reference xmls checked in and compare
> them with the generated ones. I think (I can check on Wednesday)
> that we use a subclass of FileJobManagement which suits our
> needs better. If we have to copy the current state of
> FileJobManagement and then keep on developing it on our side,
> that would be no problem, hence I would share Patrick's opinion.
>
> Regards,
> Stefan
>
> Am Freitag, 2. Januar 2015 15:31:16 UTC+1 schrieb Daniel Spilker:
>
> Is anyone using the Job DSL command
> <https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#run-a-dsl-script-locally>
> line
> <https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#generate-a-job-configxml-without-having-to-fire-up-jenkins>
> line
> <https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#generate-a-job-configxml-without-having-to-fire-up-jenkins>
> tool?
>
> I want to deprecate the command line tool and remove it in a
> future version because of several reasons:
> * Use cases for the command line tool are testing a Job DSL
> snippet, which can also be done ad-hoc on the playground
> <http://job-dsl.herokuapp.com/> or with unit tests as shown
>
> I want to deprecate the command line tool and remove it in a
> future version because of several reasons:
> * Use cases for the command line tool are testing a Job DSL
> snippet, which can also be done ad-hoc on the playground
> in the job-dsl-gradle-example
> <https://github.com/daspilker/job-dsl-gradle-example>.
> * Several new Job DSL features like generating XML depending
> on the installed plugin version or looking up credential IDs
> or config file IDs are not available in the command line tool.
> * There are no tests for the command line tool and I'm not
> testing it manually before cutting a release, so it may
> already be broken or break any time.
>
> The Job DSL uses a JobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/JobManagement.groovy>
> on the installed plugin version or looking up credential IDs
> or config file IDs are not available in the command line tool.
> * There are no tests for the command line tool and I'm not
> testing it manually before cutting a release, so it may
> already be broken or break any time.
>
> The Job DSL uses a JobManagement
> interface for interacting with backend implementations.
> Currently there are three implementations.
> JenkinsJobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-plugin/src/main/groovy/javaposse/jobdsl/plugin/JenkinsJobManagement.java>
> Currently there are three implementations.
> JenkinsJobManagement
> is used when running the plugin as build step in Jenkins,
> FileJobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/FileJobManagement.groovy>
> FileJobManagement
> is used for the command line tool and StringJobManagement
> <https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/test/groovy/javaposse/jobdsl/dsl/StringJobManagement.groovy>
> is used for internal testing. As outlined above I want to
> get rid of FileJobManagement. StringJobManagement on the
> otherhand could be useful for the playground and for unit
> testing. There has been a pull request
> <https://github.com/jenkinsci/job-dsl-plugin/pull/282> to
> get rid of FileJobManagement. StringJobManagement on the
> otherhand could be useful for the playground and for unit
> testing. There has been a pull request
> publish the JAR with the test classes to make
> StringJobManagement available to third-parties. Instead of
> publishing the test files, I want to promote
> StringJobManagement to the production classes and add proper
> tests. Then it can replace the mock implementations for the
> playground and for unittests.
>
> What do you think?
>
> Daniel
>
> --
> You received this message because you are subscribed to the
> Google Groups "job-dsl-plugin" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to job-dsl-plugi...@googlegroups.com
> <javascript:>.
> StringJobManagement available to third-parties. Instead of
> publishing the test files, I want to promote
> StringJobManagement to the production classes and add proper
> tests. Then it can replace the mock implementations for the
> playground and for unittests.
>
> What do you think?
>
> Daniel
>
> --
> You received this message because you are subscribed to the
> Google Groups "job-dsl-plugin" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to job-dsl-plugi...@googlegroups.com
> To post to this group, send email to job-dsl...@googlegroups.com
> <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/job-dsl-plugin/aa118882-c323-4b5c-a406-c6080d891e3f%40googlegroups.com
> <https://groups.google.com/d/msgid/job-dsl-plugin/aa118882-c323-4b5c-a406-c6080d891e3f%40googlegroups.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/d/msgid/job-dsl-plugin/aa118882-c323-4b5c-a406-c6080d891e3f%40googlegroups.com
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "job-dsl-plugin" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to job-dsl-plugi...@googlegroups.com
> <mailto:job-dsl-plugi...@googlegroups.com>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "job-dsl-plugin" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to job-dsl-plugi...@googlegroups.com
> To post to this group, send email to job-dsl...@googlegroups.com
> <mailto:job-dsl...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/job-dsl-plugin/7795382f-8b14-49ea-9f23-3146e07a4292%40googlegroups.com
> <https://groups.google.com/d/msgid/job-dsl-plugin/7795382f-8b14-49ea-9f23-3146e07a4292%40googlegroups.com?utm_medium=email&utm_source=footer>.
Daniel Spilker
Jan 9, 2015, 5:56:04 PM1/9/15
to job-dsl...@googlegroups.com
Thanks for the clarifications. I will keep FileJobManagement and the command line tool now as they seem to be valuable to some users. I will also promote StringJobManagement to the production classes and add some tests for both classes. But both classes will not get support any features of JobManagement beyond the current implementations unless someone comes up with a good use case.
@Patrik: Can you create a pull request for your changes to FileJobManagement? I think other users will also need the ability to generate the config files to a directory other than the current working directory.To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/54AAA1A3.6090307%40gmail.com.
Reply all
Reply to author
Forward
0 new messages