If there was ever a webpage that needed a facelift, it would be Jenkins, so hopefully this is not just a backend rewrite.
Seriously. In FF editing a job is painfully slow.
Jenkins 2.0 Beta
21–30 of 157 posts
Re: Jenkins 2.0 Beta
#22Earlier quoted context omitted.
> I came here to write sth like "still in Java... :/" And the problem with that is...?
Typical issues surrounding Java projects: - High startup time. Anything bigger than a hello world takes seconds, more typically tens of seconds, to start. My Jenkins setup takes 3 or 4 minutes before it is fully initialized. Even starting the JVM in client mode doesn't help much. I know, it's a server, and startup time doesn't matter once it's running, but it feels annoying. - High memory usage. Heaps in the 1-2 GB r…
"Heaps in the 1-2 GB range are not uncommon."
Is this really still a complaint in 2016? Your phone has that much RAM.
Honestly if you're worried about Java heap size, spin up a t2.medium instead of a t2.small for your build pipeline. Running Jenkins on a Raspberry Pi is probably not a great idea if you're writing any serious application.
Re: Jenkins 2.0 Beta
#23Having been using jenkins several times since it was Hudson, as well as Bamboo, travis-ci, python buildbot, and TeamCity, Jenkins is a loser from my perspective. Not worth becoming invested in.
Its simply too difficult to use by a laymen developer or sysadmin when accommodating complex buildchains, which only grow more complex over time in most software businesses.
If you're going to program your CI with a web administrative interface, and provide an easy to navigate interface for users, expand with build metrics and external systems, I suggest TeamCity over any others.
Though jenkins is free, my experience is maintenance teams of 2 or more people with tribal knowledge develop around the tool that far outweigh the license cost of TeamCity, which solve many of these homegrown engineered problems as part of the product cost.
If you have a strong developer team, I would suggest using something like python buildbot and programming your CI end-end in a single unified language, much better than shoe-horning plugins and groovy code inside your jenkins textarea fields!
That said, all CI systems are just software, and any requirement can be accommodated with sufficient amount of additional software, forks, or changes. Any will do.
Re: Jenkins 2.0 Beta
#24It's great to see that Jenkins is following the path blazed by GoCD[1] and Concourse[2] to make the pipeline concept more central. That said, this appears to be achieved by promoting the plugin into the default installation. It also misses some of additional the advantage Concourse holds over Jenkins and GoCD: build configuration is purely declarative and can be checked in with the project. You know what version of y…
Yeah, version control of Jenkins itself has always scared me. There seems to be a pattern that we go through. (in the beginning, there was light...) * Create a small, tight, single-purpose Jenkins job * Add a small tweak to it (repeat adding tweaks) (realize the Jenkins job now contains MANY different configurations options and the job itself is now a shell script in its own right) * Sweep the "job" into a shell scri…
We use Netflix's Job-DSL to keep Jenkins job configuration in source control (and to allow easier reuse than offered with job reuse plugins).
Re: Jenkins 2.0 Beta
#25If there was ever a webpage that needed a facelift, it would be Jenkins, so hopefully this is not just a backend rewrite.
Take a look at the Usability Section[1]
Looks like a massive facelift, and lots of work done to make things more intuitive, faster, and more pleasing to the eye.
Re: Jenkins 2.0 Beta
#26It's great to see that Jenkins is following the path blazed by GoCD[1] and Concourse[2] to make the pipeline concept more central. That said, this appears to be achieved by promoting the plugin into the default installation. It also misses some of additional the advantage Concourse holds over Jenkins and GoCD: build configuration is purely declarative and can be checked in with the project. You know what version of y…
Yeah, version control of Jenkins itself has always scared me. There seems to be a pattern that we go through. (in the beginning, there was light...) * Create a small, tight, single-purpose Jenkins job * Add a small tweak to it (repeat adding tweaks) (realize the Jenkins job now contains MANY different configurations options and the job itself is now a shell script in its own right) * Sweep the "job" into a shell scri…
I mentioned this elsewhere in the thread, but here goes:
https://zwischenzugs.wordpress.com/2016/01/24/ci-as-code-sta... https://zwischenzugs.wordpress.com/2016/01/30/ci-as-code-par... https://zwischenzugs.wordpress.com/2016/02/25/922/
Re: Jenkins 2.0 Beta
#27Having been using jenkins several times since it was Hudson, as well as Bamboo, travis-ci, python buildbot, and TeamCity, Jenkins is a loser from my perspective. Not worth becoming invested in. Its simply too difficult to use by a laymen developer or sysadmin when accommodating complex buildchains, which only grow more complex over time in most software businesses. If you're going to program your CI with a web admini…
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.
Re: Jenkins 2.0 Beta
#28It's cool that they're promoting the "pipeline" plugin to a built-in feature, but the devil is in the details.
Under the hood, it's implemented by taking a script written in a "DSL" (it's actually Groovy code), transforming it into continuation-passing style, and serializing its state. This is pretty cool from a theoretical CS perspective, but having played with it a little bit, the implementation seems very fragile. There are a number of long-standing unfixed bugs that cause the transformed code to misbehave in ways that you wouldn't predict just from looking at it, even if you're experienced with Groovy. I ran into a couple of them just during a brief period of experimentation. For instance:
https://issues.jenkins-ci.org/browse/JENKINS-27893 (varargs are mishandled)
https://issues.jenkins-ci.org/browse/JENKINS-28277 (currying doesn't work)
https://issues.jenkins-ci.org/browse/JENKINS-26481 (calling a closure in a loop doesn't work right)
https://issues.jenkins-ci.org/browse/JENKINS-28183 (killing a pipeline job doesn't clean up its state properly)
And there are inherent limitations to the approach; for instance, you can't store any non-serializable values in local variables, which means simple things like foreach loops don't work (because you can't serialize an iterator).
I really like the idea behind the Pipelines feature, in principle. But I think building it around a general-purpose programming language, and then failing to support all of that language's features, is a recipe for headaches. If you never try to do anything more complicated than what's shown in the examples then you should be fine, but the borders between what works and what doesn't are very ill-defined.
EDIT: Oh yeah, and there's a surprising amount of functionality that isn't documented anywhere except for blog posts and JIRA tickets.
Re: Jenkins 2.0 Beta
#29Having been using jenkins several times since it was Hudson, as well as Bamboo, travis-ci, python buildbot, and TeamCity, Jenkins is a loser from my perspective. Not worth becoming invested in. Its simply too difficult to use by a laymen developer or sysadmin when accommodating complex buildchains, which only grow more complex over time in most software businesses. If you're going to program your CI with a web admini…
If you're putting lots of logic into ANY CI server you're doing it wrong!
Script your build so that you can run it with a single command on any build server or any developer machine. Then have the build server invoke said scripts (with arguments for any build-server specific paths etc).
Having spent a week fixing problems with inter-plugin dependencies I do agree with your point - Jenkins just isn't very good, like a lot of the free software from that generation (FitNess etc).
Re: Jenkins 2.0 Beta
#30Having been using jenkins several times since it was Hudson, as well as Bamboo, travis-ci, python buildbot, and TeamCity, Jenkins is a loser from my perspective. Not worth becoming invested in. Its simply too difficult to use by a laymen developer or sysadmin when accommodating complex buildchains, which only grow more complex over time in most software businesses. If you're going to program your CI with a web admini…
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.
being able to config jenkins via code is huge! looking forward to trying it