Re: Versioning the entrie system configuration -- not artifacts
Thanks but I was doing CI in 1980 and it is IMO a non started that the core system doesn't implement versioning and uses a local file store instead of a network based store. Given the advances in technology I am seeing less and less value in systems that require more and more plugins for basic things that should be part of the core. On Monday, November 7, 2016 at 7:45:57 AM UTC-5, Rinaldo DiGiorgio wrote: > > Hi, > > I tried to version my jobs with the Jobs SCM plugin for example and it > often gets confused and ends up making my system unusable. Perhaps an > entire rewrite is needed and the backend store needs to move to something > like redis. I don't think version control should be done with optional > plugins. It should be part of the core system and all configuration data > should be in a network store. > > I can see a solution using docker where one makes a base image. What > happens when you change the configuration however. Do you make a new docker > base image? Some organizations want all the source code to generate an > image in some type of SCM and this is the issue. If you change job > configurations or config params you just incurred the hit of a new image > generation cycle. Perhaps I am not looking it in the right way or in the > future when everything is pipeline the configuration is pipeline with > supporting json and property files. > > Rinald > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/310010e3-af9c-4091-ba56-44a54510cff2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Versioning the entrie system configuration -- not artifacts
I did not mean to start a religious war - like I said, this is only an opinion. I only offered that Pipelines are a bit newer - and while CPS is a bear, it does appear, at least to me, to simplify things drastically - allowing much simpler setups and avoiding situations where it "gets confused and ends up making my system unusable". Perhaps this is the answer to original poster's current frustrations. Or maybe not. -M On Monday, November 7, 2016 at 2:23:12 PM UTC-8, Victor Martinez wrote: > > Both of them are good but they have different approaches... Although, IMO, > Pipeline is still an incubating feature atm. > I wouldn't say Pipelines are better or worst or even obsolete or modern. > If you go for configuration as code, by definition, code should be > testable, and I could go further by saying testable locally and > automatically, and unfortunately I haven't not seen that feature yet with > the Pipelines. > > Cheers > > On Monday, 7 November 2016 20:53:35 UTC, Michael Lasevich wrote: >> >> Ahh, "Job DSL", I remember that. It was a good thing when it was the >> only game in town, but (in my opinion) Pipelines pretty much made it >> obsolete. Of course it is a matter of opinion, but if you are finding Jobs >> DSL too complicated, Pipelines may be just right for you - it removes a lot >> of the complexity, and makes your entire build process far simpler - you no >> longer need a rabbit-warren of jobs, and with MultiBranch Pipelines + >> Global Libs + something like Slack notifications, your devs may not even >> need to login to Jenkins server - just commit code and see notification >> that the job was created(if needed) and build was complete :-) Join the >> modern age :-) >> >> -M >> >> On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote: >>> >>> Give a try job-dsl-plugin >>> - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin >>> >>> Supports 1000+ jenkins plugins, local testing, gradle integration, same >>> Jenkins job paradigm, DRY concept and a bunch of other benefits besides of >>> converting jobs in code and therefore scm oriented. >>> >>> Cheers >>> >>> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/372afae4-6fb7-4b7a-9ccc-5308d9e0f629%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Versioning the entrie system configuration -- not artifacts
On Mon, Nov 7, 2016 at 3:53 PM, Michael Lasevichwrote: > Ahh, "Job DSL", I remember that. It was a good thing when it was the only > game in town, but (in my opinion) Pipelines pretty much made it obsolete. Of > course it is a matter of opinion, but if you are finding Jobs DSL too > complicated, Pipelines may be just right for you - it removes a lot of the > complexity, and makes your entire build process far simpler - you no longer > need a rabbit-warren of jobs, and with MultiBranch Pipelines + Global Libs + > something like Slack notifications, your devs may not even need to login to > Jenkins server - just commit code and see notification that the job was > created(if needed) and build was complete :-) Join the modern age :-) The big limitation of Pipelines is that Pipelines' Groovy code isn't actually Groovy. It's a small-ish subset of Groovy that breaks in ways that aren't extremely well-documented. You can't just import any arbitrary Groovy code and expect it to work. A lot of folks who are currently using the Groovy plugin running system groovy or external groovy scripts will have to do major rewrites to dumb things down for the Pipeline plugin. Until/unless pipelines support all of Groovy, it's difficult to recommend for scripts larger than a couple of lines. IMO, anyway. Sean > > -M > > On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote: >> >> Give a try job-dsl-plugin >> - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin >> >> Supports 1000+ jenkins plugins, local testing, gradle integration, same >> Jenkins job paradigm, DRY concept and a bunch of other benefits besides of >> converting jobs in code and therefore scm oriented. >> >> Cheers > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/5200fb48-2be3-4f51-a26f-08681272a80c%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPAActcpPLKXV%2B7S-p1oqELrw0u0p8L_Z0imP14j1ozMddDpBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Versioning the entrie system configuration -- not artifacts
Both of them are good but they have different approaches... Although, IMO, Pipeline is still an incubating feature atm. I wouldn't say Pipelines are better or worst or even obsolete or modern. If you go for configuration as code, by definition, code should be testable, and I could go further by saying testable locally and automatically, and unfortunately I haven't not seen that feature yet with the Pipelines. Cheers On Monday, 7 November 2016 20:53:35 UTC, Michael Lasevich wrote: > > Ahh, "Job DSL", I remember that. It was a good thing when it was the only > game in town, but (in my opinion) Pipelines pretty much made it obsolete. > Of course it is a matter of opinion, but if you are finding Jobs DSL too > complicated, Pipelines may be just right for you - it removes a lot of the > complexity, and makes your entire build process far simpler - you no longer > need a rabbit-warren of jobs, and with MultiBranch Pipelines + Global Libs > + something like Slack notifications, your devs may not even need to login > to Jenkins server - just commit code and see notification that the job was > created(if needed) and build was complete :-) Join the modern age :-) > > -M > > On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote: >> >> Give a try job-dsl-plugin >> - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin >> >> Supports 1000+ jenkins plugins, local testing, gradle integration, same >> Jenkins job paradigm, DRY concept and a bunch of other benefits besides of >> converting jobs in code and therefore scm oriented. >> >> Cheers >> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/82387c59-9217-42fb-bbe3-d8ce9740b114%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Versioning the entrie system configuration -- not artifacts
Ahh, "Job DSL", I remember that. It was a good thing when it was the only game in town, but (in my opinion) Pipelines pretty much made it obsolete. Of course it is a matter of opinion, but if you are finding Jobs DSL too complicated, Pipelines may be just right for you - it removes a lot of the complexity, and makes your entire build process far simpler - you no longer need a rabbit-warren of jobs, and with MultiBranch Pipelines + Global Libs + something like Slack notifications, your devs may not even need to login to Jenkins server - just commit code and see notification that the job was created(if needed) and build was complete :-) Join the modern age :-) -M On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote: > > Give a try job-dsl-plugin > - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin > > Supports 1000+ jenkins plugins, local testing, gradle integration, same > Jenkins job paradigm, DRY concept and a bunch of other benefits besides of > converting jobs in code and therefore scm oriented. > > Cheers > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5200fb48-2be3-4f51-a26f-08681272a80c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Versioning the entrie system configuration -- not artifacts
Give a try job-dsl-plugin - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin Supports 1000+ jenkins plugins, local testing, gradle integration, same Jenkins job paradigm, DRY concept and a bunch of other benefits besides of converting jobs in code and therefore scm oriented. Cheers -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1106951a-b4c3-4288-a5d6-2ec8bccd6bc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Versioning the entrie system configuration -- not artifacts
Not familiar with "Jobs SCM" and unclear as to what you are trying to do - or how Redis or Docker fits it here. If you have some idea, you are welcome to write a plugin and make it work however you want, which is why the plugin system exists - and answers your question as to why this is done with plugin. But onestly, it sounds like you are making it far more complicated than it needs to be. Generally the setup would be a single, static Jenkins Master server that manages job scheduling and coordination and a number of "slave" nodes" that execute the job. Ideally slave nodes would be pristine and disposable and not have any code/tools installed on them - with master managing any code/tools requires - meaning they do not ever need to be versioned on the slave. Modern way of managing your jobs is via Pipelines. You just store your jobs along with your code (I assume your code is in some sort of a SCM to begin with) and for shared libraries use global library repo(s). Jenkins does not really have a lot of configuration on Jenkins Master side after this, the only thing you really need here is a decent backup strategy - but if you are really interested in tracking individual job changes, there is a "Job Configuration History" plugin that will track each change and who did it, but with most of the job coming with source code, it is not all that critical/necessary. HTH, -M On Monday, November 7, 2016 at 4:45:57 AM UTC-8, Rinaldo DiGiorgio wrote: > > Hi, > > I tried to version my jobs with the Jobs SCM plugin for example and it > often gets confused and ends up making my system unusable. Perhaps an > entire rewrite is needed and the backend store needs to move to something > like redis. I don't think version control should be done with optional > plugins. It should be part of the core system and all configuration data > should be in a network store. > > I can see a solution using docker where one makes a base image. What > happens when you change the configuration however. Do you make a new docker > base image? Some organizations want all the source code to generate an > image in some type of SCM and this is the issue. If you change job > configurations or config params you just incurred the hit of a new image > generation cycle. Perhaps I am not looking it in the right way or in the > future when everything is pipeline the configuration is pipeline with > supporting json and property files. > > Rinald > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9547956d-bf32-4827-ab38-bbaf41b971f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.