Hi all, I will first take the opportunity to introduce myself. I am Thorsten Scherler one of the "new faces" and since the beginning of the year one of the front-end developer of blueocean. I have a long track record in open source development mainly in the ASF, where I was contributing mostly to the Cocoon based projects (Lenya, Forrest and Coocon). Weapon of choice had been java and xslt back then. Since around 3/4 years I started to switch to node.js and javascript as preferred technology stack. ATM I am the "react guy" in the blueocean team.
I used hudson/jenkins since the beginning with different technologies and projects. Last year I was lucky to had the opportunity to be on the team that created http://www.kaba.com/exivo which is 100% based on js, node.js, CQRS, Distributed Domain Driven Design and React.js. I mention this since we did something like "pipeline" with dependent jenkins projects but based on "normal" build jobs (of course there had not been a cool overview of the steps and how there had been connected). Only a couple of developer where able to fix the build scripts when things started to get weird since it were a good mix of docker, shell and js script magic and quite fragile. Anyway we made it work to the point where we implement a kind of CD, not pretty but fully functional. When I wrote my first Jenkinsfile for the jenkins-plugin-site I struggled a bit as well to "use" groovy to write it, but as Stephen stated I did the "dirty" work in my "normal" shell scripts and this way had nearly no contact to use groovy at all and my scripts are as testable as they had been before. Since I wrote the views on pipeline/multibranch/PR I had to create a couple of pipeline scripts and Jenkinsfile to get real data in my development environment. I found the widget that generates you groovy code snippet very helpful, but as said I did not do rocket science just created pipelines to generate me some testing data. In my opinion in the future pipeline scripts should be created by drag and drop, so I could use Jenkins to generate me a Jenkinsfile without having to see the generated code at all. A "manager" without technology knowledge (if that still exists nowadays) should be able to create a CD pipeline only using a smart wizard. Regarding the principal discussion whether there should be something like Jenkinsfile I think we only have to look on all the Dockerfiles, .travis.yml etc. to realized that this is a common practise and further brings lots of advantages. You keep the information on how jenkins/docker/travis should treat your project in your project and do not have to configure any jenkins/docker/travis instance to treat your project right. That is the killer feature which would have saved my last project A LOT of TIME since instead to configure our 3/4 different staging environments in the running instance we would have just created a Jenkinsfile which described the build/testing pipeline and reused it in all our env. Anyway I hope as soon you have played around a bit with blueocean you will find that what it does right now it does much better then the current alternative in direct comparison. What it will do in the future depends on YOU since it an open source project after all. ...as always for any given OS-project patches are welcome. ; salu2 On Friday, May 27, 2016 at 8:35:08 PM UTC+2, Stephen Connolly wrote: > > The Jenkins specific tasks should be mostly single purpose and logicless > in my view. > > The complex logic should be testable outside of Jenkins. > > But building complex logic in groovy "just because it is there" and not > "because we cannot do it elsewhere" is the problem my rant is directed at > > On Friday 27 May 2016, Maciej Jaros <[email protected] <javascript:>> > wrote: > >> Stephen Connolly (2016-05-27 12:12): >> >> >> >> On 27 May 2016 at 07:59, Craig Rodrigues <[email protected]> wrote: >> >>> Hi, >>> >>> The new Jenkins UI looks nice, and will be a big improvement over the >>> existing UI. >>> >>> The original selling point of Jenkins was that even with the simplistic >>> forms-based UI, >>> someone could fill out a relatively simple form, and have a continuous >>> integration pipeline. >>> I have met people who were general devops and scripting people, and >>> could use Jenkins quite nicely. >>> >>> While I understand the motivation for Pipeline (previously known as >>> Workflow), I can't say I'm very happy with the results. >>> >>> Here are some of the pain points I've encountered with Pipeline scripts: >>> >>> - Other than the most trivial of scripts, you need to be a >>> knowledgable Groovy programmer. For example, to make a global variable, >>> you need to use a @Field. (What?!) Most scripting and devops people >>> that >>> I know don't really know Groovy. >>> >>> So in my personal opinion, this is a sign of People Doing Things Wrong™ >> >> By this I mean that your Jenkinsfile should *not* be doing complex >> things. You should have shell scripts or equivalent to do the complex >> functionality. That lets you test each individual step in the phase on >> local developer machines. Then your pipeline should end up mostly being >> >> >> But you cannot test everything locally, because you e.g. don't have build >> parameters, you might not have certain SSH credentials defined... That said >> I do tend to move everything to scripts, but this really defeats the >> purpose of almost all Jenkins plugins... And plugins gives you some >> integrations (especially with credentials) you don't have in scripts. And >> it's much easier to add build step for triggering e.g. call of another >> project and passing all parameters to it from current build (which BTW is >> overly hard with Groovy). >> >> Regards, >> Nux. >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/fac125e7-9e6c-46f1-bbe7-42067660d98c%40mol.com.pl >> >> <https://groups.google.com/d/msgid/jenkinsci-users/fac125e7-9e6c-46f1-bbe7-42067660d98c%40mol.com.pl?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Sent from my phone > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/6e759b1c-7250-4ba8-9cce-85f4d8d3e958%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
