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

111–120 of 157 posts

Re: Jenkins 2.0 Beta

#111

Post by pron »

incepted wrote: post #107
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 D…

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

Not as easy as it sounds. If the DSL is rich enough, and if the types are handled by the host language, type errors can become just as cryptic and unhelpful as with an untyped DSLs, and it's just as hard for the IDE to do something meaningful with them.

Re: Jenkins 2.0 Beta

#112

Post by quacker »

hidingfornow wrote: post #55

I've been tasked with implementing a large Jenkins deployment to support a ton of teams and I don't think I've hated a piece of software so much in such a long time. The past few years I've been using other CI systems like Circle and I totally forgot how much you have to fight Jenkins. The UI is atrocious, job state is spread out among tons of crappy xml files, and the plugin system causes tons of headaches. If you'r…

You should definitely check out Jenkins Job Builder - http://docs.openstack.org/infra/jenkins-job-builder/. It lets you store job configs as nice yaml files which can be checked in to version control. It's what openstack uses to manage jobs for the many many openstack projects. I've been using for a year or so at work and highly recommend it.

Re: Jenkins 2.0 Beta

#113

Post by incepted »

pron wrote: post #111
incepted wrote: post #107

Earlier quoted context omitted.

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

> 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. Not as easy as it sounds. If the DSL is rich enough, and if the types are handled by the host language, type errors can become just as cryptic and unhelpful as with an untyped DSLs, and it's just as hard for the IDE to do somet…

Sure, but at least, auto completion works automatically.

With dynamically typed languages, you get cryptic (and vague) errors and auto completion just can't work.

Re: Jenkins 2.0 Beta

#114

Post by [deleted] »

oakhaven wrote: post #69
mark242 wrote: post #22

Earlier quoted context omitted.

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

In the simplest case, Jenkins is just polling and cloning git repos, and then spawning some tests. This plus config parsing and web frontend is not a 1GB RAM job.

[deleted]

Re: Jenkins 2.0 Beta

#115

Post by mbrock »

robbiemitchell wrote: post #110
Joky wrote: post #93

Earlier quoted context omitted.

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.

There are good reasons to prefer free and open systems, even for "production" software. Those reasons are part of why people choose to use GNU/Linux, nginx, and all the rest of the open infrastructure.

Re: Jenkins 2.0 Beta

#116

Post by Alupis »

derFunk wrote: post #74
Alupis wrote: post #3

I've been using Jenkins for years, and have been overwhelmingly happy. 2.0 is a big step for the project, congrats! The flexibility Jenkins provides as build system is enormous. The plugin community is also a huge benefit -- chances are, if you have a need, there's a plugin for it.

I feel the same. Using Jenkins since 5 years now on a daily basis. Yet I also feel it may be coming too late. During the past 5 years our projects have grown to a size were we're expecting to have more than 1m DAU end of this year, and I don't think Jenkins will survive this journey with us. I'm speaking about scripted Docker container baking & deployments to e.g. ECS, ECR, asset uploads and versioning, basically rel…

Well, I don't know your specific circumstances, but I'll say one should strive to have as little logic in their build system as possible.

It essentially should be running shell scripts and/or language-specific build scripts/tools. All logic should be self-contained in your project(s) repos, so that it doesn't really matter what build system you use, and/or one could build the project without the build server if required.

With that said, I don't see any reason why release management, containerizing, versioning of assets, etc... could not all be done with Jenkins (or any build system).

Re: Jenkins 2.0 Beta

#117

Post by lispm »

solipsism wrote: post #108
GFK_of_xmaspast wrote: post #83

Earlier quoted context omitted.

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.

There are a lot DSLs writtn in Lisp, which don't use Lisp syntax and are not embedded.

Re: Jenkins 2.0 Beta

#119

Post by icebraining »

incepted wrote: post #113
pron wrote: post #111

Earlier quoted context omitted.

> 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. Not as easy as it sounds. If the DSL is rich enough, and if the types are handled by the host language, type errors can become just as cryptic and unhelpful as with an untyped DSLs, and it's just as hard for the IDE to do somet…

Sure, but at least, auto completion works automatically. With dynamically typed languages, you get cryptic (and vague) errors and auto completion just can't work.

I use auto-completion in Python every day with PyDev. It's not as advanced as for other languages, but "just can't work" is not really true either.

http://www.pydev.org/manual_adv_complctx.html

Re: Jenkins 2.0 Beta

#120

Post by radicalbyte »

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…

Huh? I really don't understand your argument. Jenkins is better than scripts because you can do more in Jenkins than in scripts? O_O

You can do a heck of a lot more in scripts; you've got a full language with all of the libraries it comes with in order to do stuff.

We've build our current build pipeline with Python scripts:

0. Bootstrap the build environment (installs everything you need to build). 1. Build projects order, order is derived from the intermodule dependency graph. 2. Execute unit test sets based on build parameter + save results in output. 3. Execute integration tests based on build parameter + save results in output. 4. Build distribution packages + save in output. 5. Deploy distribution packages to server based on parameters. 6. Run UI tests against the deployed packages + save results in output. 7. Publish the bits if they're OK.

Most of these steps are in different scripts, which can be called either from orchestration scripts or one-for-one in Jenkins.

All we have Jenkins do is invoke the script(s) then process and report the results.

We've basically got it wrong with the design of our CI tools; they do too much. They should just provide scheduling, invocation, reporting and dashboards over the build process. Expose that as an API and let scripts integrate with it.

Post reply on HN