Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jenkins 2.0 Beta

jenkins.io

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Jenkins 2.0 Beta

#101

Post by solipsism »

christop wrote: post #78
solipsism wrote: post #70

Earlier quoted context omitted.

And 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.

In 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?

In 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.

Re: Jenkins 2.0 Beta

#102

Post by jacques_chester »

stephenconnolly wrote: post #59
jacques_chester wrote: post #13

It'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…

> build configuration is purely declarative and can be checked in with the project. Seems like you are missing the point of pipeline and the Jenkinsfile concept, namely that the pipeline is part of the SCM. Yes you can have the pipeline defined in the old-style text box in the job config, but that is intended to be used only while you develop the pipeline. Once you get it developed it gets checked in to source contro…

> Seems like you are missing the point of pipeline and the Jenkinsfile concept, namely that the pipeline is part of the SCM.

I guess I missed that Jenkins is heading that way. It's what Concourse does and I'm a fan of having CI/CD live in the repo.

> For me the real advantage in pipeline is the organization folders support. You can tell Jenkins to scan all the repositories in your GitHub org and automatically create Jenkins jobs for any branches of any repositories that have a Jenkinsfile... PRs will automatically (subject to basic drive-by hack protection) be built and the commit will be tagged with the result.

For PR-building on Concourse, the resource I'd recommend is: https://github.com/jtarchie/pullrequest-resource

> we are providing some opinionated defaults (which is a change from the 1.x series)

I see this more and more in the Java ecosystem and I think it's a good thing.

> I might have a different view on that claim, but hey I'm significantly biased.

Me too! :)

> OTOH my personal view is that for the 99% of jobs pipeline is overkill

I am starting to head in the other direction. We've historically fallen into creating "big ball of mud" build systems because it was just too hard to easily decompose and manage them as smaller units that could be rearranged quickly and safely.

Concourse makes it so trivial that the gradient for what is easy points in the other direction. It is less painful to lay out a pipeline (a graph, really) of builds that are composed of small pieces, than to have one gigantic Build To Rule Them All.

In Pivotal the practices around Concourse are evolving extremely quickly, because teams are discovering that it's really easy to delegate more and more to it. You start with a simple git->unit->feature->deploy pipeline, but soon you realise it's easy to assemble all sorts of things. The best is yet to come.

Re: Jenkins 2.0 Beta

#103

Post by vacri »

jquast wrote: post #23

Having 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…

I tried buildbot, and found that the documentation didn't match observed behaviour, and their insistence on not providing any examples (combined with some in-house jargon) because "everyone is different" made the whole process particularly painful. Buildbot required a lot of attention and time to get working for us, and after all that, wasn't particularly end-user friendly. You're going to get exactly the same '2 people with tribal knowledge' if you use buildbot.

Re: Jenkins 2.0 Beta

#104

Post by fathom108 »

zabilcm wrote: post #94
nod wrote: post #46

Earlier quoted context omitted.

If we were hypothetically "too big" for TeamCity, with scaling difficulties all over, do you have (or have heard) any recommendations? I hear the biggest companies all roll their own, but is there anything between TeamCity and Google-scale?

There's http://go.cd if you are looking at something focused on CD (Pipelines etc)

Yes, we've found gocd does a terrific job of allowing you cleanly model your full continuous delivery workflow and organize your servers.

Re: Jenkins 2.0 Beta

#105

Post by brightball »

jquast wrote: post #23

Having 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…

The biggest thing is that Jenkins is a job engine, not a CI server. Because it CI happens to be nothing more than executing jobs when triggered and then tracking/reporting the results Jenkins gets used for it as well as a number of other things.

If you're looking at Jenkins purely as a CI then absolutely, it's overkill. I've seen Jenkins used as a distributed cron replacement, CI server, pingdom replacement, deployer and even as a means to give non-programmers permission controlled access to execute certain jobs via parameterized builds. Just having granular control to decide how to report on cron failures from a central location is a huge help.

It's ability to combine job execution, detailed result tracking, scheduling, scripting, SSH and failure reporting from a central location with flexible permissions makes it an extremely useful tool.

The extensions that the Cloudbees folks have put together are pretty sharp too.

Re: Jenkins 2.0 Beta

#107

Post by incepted »

teraflop wrote: post #28

It'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.…

DSL are certainly the future of this kind of tools but not with a dynamically typed language like Groovy. The fact that it's dynamically typed makes it pretty much impossible to get decent support from IDE's. Gradle's support in IDEA has been broken forever, and you know that even if the JetBrains guys can't pull it off, it can't be pulled off.

I think the future belongs to statically typed languages that can offer DSL's as terse as Groovy but with actually types in them, so that the IDE can actually do the job it's being paid for.

Re: Jenkins 2.0 Beta

#108

Post by solipsism »

GFK_of_xmaspast wrote: post #83
unclebucknasty wrote: post #81

Earlier quoted context omitted.

Ugh. 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 wil…

But all the lisp people always talk about how incredible it is that one can have all sorts of DSLs....

Completely 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.

Re: Jenkins 2.0 Beta

#109

Post by incepted »

FooBarWidget wrote: post #11
Alupis wrote: post #6

Earlier 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…

> High startup time. Anything bigger than a hello world takes seconds

Oh, no! Seconds? Like five? Seven? For a process that you start less than once a day? Unacceptable.

> High memory usage. Heaps in the 1-2 GB range are not uncommon.

So... what? Spend an additional $30 on your build server and add 8Gb to it. Problem solved.

> - XML configuration files.

XML is fine. As opposed to Groovy, IDE's do a great job at offering auto-completion on it. But if Groovy is your bag, you can use that too.

> - Non-Unixy feel.

I have no idea what that means and I've been using UNIX for about thirty years now.

Re: Jenkins 2.0 Beta

#110

Post by robbiemitchell »

Joky wrote: post #93
radicalbyte wrote: post #29

Earlier quoted context omitted.

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…

You have simple problems to suggest simple solutions. CI logic can gets complicated: What about cascade builds? The pipeline can't be handled in your build script. What about reporting? (list of compiler warnings in the build? List of tests that failed? In general extracting information from the log) What about efficient email alert? (with blame list, list of changes, etc.) What about IRC reporting? Jenkins is not ve…

This is a critical component of releasing production software. I would not expect to see "free" in the conversation here.
Post reply on HN