On 27 May 2016 at 11:12, Stephen Connolly <[email protected]> wrote:
> > > 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 > > node { > try { > sh "..." > stash ... > } catch (...) { > sh "..." > } finally { > sh "..." > } > } > input "..." > node { > unstash > sh "..." > } > > Ok you may have to chain parameters between steps, etc. but what I see > people doing instead is building up a whole big set of logic in the > Jenkinsfile. > > Now there is nothing "wrong" in building up that login in your > Jenkinsfile... but in my view it is Wrong™ because: > > - You now can only test this logic by running Jenkins builds. > - You cannot unit test this logic, you can only run manual acceptance > tests on the whole script > - You will need to battle with the script approval process if security > of your instance is important to you > - You have tied yourself to Jenkins (which initially seems tempting > for Jenkins, but people who feel tied to a system are then not free to > explore other options and probably are more correctly tied to a "specific > way of doing things", so they cannot even explore alternatives *within > Jenkins*... then when they finally get fed-up they blame Jenkins rather > than their choices in how to use Jenkins... so it ends up being a loss of > Jenkins when people tie themselves to "*their way* of using Jenkins") > > For what it is worth, this last point is not just a problem for Jenkins, we have the same issue with Maven. Do you not like Maven? Perhaps what you really don't like is that the people who wrote your pom.xml chose to make it a 10,000+ line epic rather than encapsulate the logic into custom plugins and a custom lifecycle. If you are Doing Maven The Right Way™ then your pom.xml should be <project> <modelVersion>4.0.0</modelVersion> <!-- optional --> <parent> ... </parent> <!-- /optional --> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <packaging>*custom-packaging*</packaging> <dependencies> ... *insert dependencies here* ... </dependencies> <build> <plugins> <plugin> <groupId>...</groupId> <artifactId>*custom-plugin*</artifactId> <version>...</version> *<extensions>true</extensions>* </plugin> </plugins> </build> </project> If you have anything more that the above *then you have chosen to fight Maven*. When you fight Maven, Maven *always* wins the war... which means you loose Other build systems (i'm looking at you gradle) make it easy to embed small bits of custom logic and stave off having to stop for a second and think about that custom logic and then embed that logic into a Maven plugin... now that is indeed tempting for the once off project... but every time you release a new version of that project, those are repeated builds. If the process is really a once-off, just capture the output and check it into source control ;-) It is much better to slow down for a couple of minutes and encapsulate that logic into a custom plugin that can make reuse easier. (Note I will agree with anyone who complains that writing Maven plugins is not as easy as it should be... but that is a different story that results from most people refusing to even try) > >> - Documentation for Pipeline scripts isn't that great (although it >> has definitely been improving). In all honesty, I cannot point a junior >> scripting person to write a good Pipeline script for developing a build >> Pipeline. >> >> Documentation will improve. > >> >> - The durable task plugin which invokes shell commands on Unix, and >> batch jobs on Windows goes through an elaborate method for invoking shell >> commands. It is very, very difficult to grab the exit status of commands, >> stderr, stdout, etc. For a while, these wrappers would do things like not >> detect when a command had terminated, etc. (Looks like this has been fixed >> now) >> >> I hear you. It is a trade-off but being restartable is too much of a > killer feature, so I view it as worth the pain of some initial bugs. > >> >> - It is very hard to figure out how to cancel a running Pipeline >> job. The UI link to "Click here to cancel" a Pipeline job is hidden in >> the >> build output, and often doesn't work. >> >> I hear you and feel your pain too. > > >> I understand that Jenkins is going through a big transition period. >> Hopefully at the end of the road, things will be much better. >> However, at this point in time, I would say that in many ways, the >> current direction is *worse* than the old way of doing things with the >> old Jenkins UI. >> The old way has problems, but it was easy to figure out, and didn't have >> a lot of these intermediate layers that try to abstract things out, >> but make things harder to figure out what is going on. >> >> -- >> Craig >> >> >> >> On Thu, May 26, 2016 at 3:21 PM, James Dumay <[email protected]> >> wrote: >> >>> >>> Today we’ve made the source code >>> <https://github.com/cloudbees/blueocean> available on Github, written a blog >>> post <https://jenkins.io/blog/2016/05/26/introducing-blue-ocean/> and >>> created >>> a video <https://www.youtube.com/watch?v=3dITffteCD4> explaining the >>> project in more detail. We will be posting more updates to both the blog >>> and mailing lists when there are more updates to share. >>> >>> -- >> 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/CAG%3DrPVdhtQabPM4PjowXGssk-Rpr7X6%3DfQZASCZo9cq99vTfcQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-users/CAG%3DrPVdhtQabPM4PjowXGssk-Rpr7X6%3DfQZASCZo9cq99vTfcQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMyqp%3DwDXDc%2B-T_ejsk6Q5KMq%2BX1XAcZQuk9P7zFAnf8DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
