4 ms·
Yes, software is harder to manage (long-term) when the primary interface is a GUI. However, the new Jenkins 2.0 fixes many of the issues you've described. Buil
by robbyt 11y ago
Yes, software is harder to manage (long-term) when the primary interface is a GUI.
However, the new Jenkins 2.0 fixes many of the issues you've described. Build pipelines are a major new feature, as well as the integration of a "Jenkinsfile" which allows configuration of jobs via a proprietary DSL.
- pswenson 11y agobeing able to config jenkins via code is huge! looking forward to trying it
- solipsism 11y agothe integration of a "Jenkinsfile" which allows configuration of jobs via a proprietary DSL This makes no sense to me. Only how my project is built should be checked into the project's repo, not the whole CI/CD deployment pipeline! If I start deploying to Azure instead of AWS I need to commit that change to my project? It's nonsense.
- christop 11y agoThe DSL can pull in other scripts from elsewhere, so you could just have a stub Jenkinsfile in your project, with the bulk of the pipeline config version-controlled in another repo.
- solipsism 11y agoAnd if I change where I keep my pipeline config, I have to commit a change to the project so it grabs it from the new place? Or pass it in as a parameter, so you need to know ahead of time what parameters the DSL will be expecting? Come on now, we don't need to go to these contortions just to avoid saying that Jenkins is doing it wrong.
- christop 11y agoIn this situation, yes. You could indeed just use the Jenkinsfile for building a project. You can also specify the DSL config directly in a job, e.g. in a separate deployment job. What would be the right place to define the deployment config?
- solipsism 11y agoIn the job itself is fine... unless you want to version control it. This is a historical Jenkins weak-point. The plugins that exist to try to solve the problem are clumsy. This Jenkinsfile is their solution to the problem. I'm saying it's not a very well thought-out solution, because now they're forcing us to put this thing that's not part of the project in the project, if we want it version-controlled.
- empath75 11y agoSo don't use the Jenkins file. I have mine in a separate repo.
- Macha 11y agoWe use the pipeline plugin in my job and we use a seperate repo for pretty much the same reason. It's not a detail that's really part of the application (do you keep your chef cookbooks in the same repo?) and not only that but we use the same scripts across multiple apps.
- unclebucknasty 11y agoUgh. Not another proprietary DSL. There is something amiss in the tech world these days. Too much esoterica and too many specialized tools, too many points of failure and dependencies, and too much duct tape. But, mostly, too much reinvention for frequently incremental "gains". It seems normal, but it's really a mess. Environments are overly complex and it's a wonder anything works half the time. At some point we will completely jump the shark. From there, my bet is there'll be a powerful movement towards simplicity. /rant
- GFK_of_xmaspast 11y agoBut all the lisp people always talk about how incredible it is that one can have all sorts of DSLs....
- solipsism 11y agoCompletely different. The Groovy DSL is a limited subset of Groovy. Lisp DSLs are embedded DSLs. They're libraries that help you write code in what looks like a new language, but the entirety of lisp remains at your disposal.
- lispm 11y agoThere are a lot DSLs writtn in Lisp, which don't use Lisp syntax and are not embedded.