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

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

Re: Versioning the entrie system configuration -- not artifacts

On Mon, Nov 7, 2016 at 3:53 PM, 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

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

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

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

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