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

131–140 of 157 posts

Re: Jenkins 2.0 Beta

#131

Post by mkobit »

code_research wrote: post #125
kbody wrote: post #124

Earlier quoted context omitted.

"projectroot/config" it's too common and already used in different ways that will produce conflicts. If something is established it should be done in a proper way through a spec like semver was established.

you could avoid conflicts by not naming your project files "Dockerfile" or "Jenkinsfile" or "travis.yml"...

I don't like the Dockerfile or Jenkinsfile either, but I can kind of understand the .travis.yml. The good thing about the "Dockerfile" is that with most of the docker commands that interact with it, you can use the '-f' option to specify the file. For example "docker build -f dockerfiles/application.dockerfile" -t myapplication .". I don't see any easy way to do that with the Jenkinsfile.

The amount of top-level files in these projects has started to become quite large, and it is unclear at first glance to see what it is important when exploring a new ecosystem.

I'd like to see these products would move in a direction where these were would do any/some of the following:

1) use a file extension rather than "important" describing filename (.docker for Dockerfiles and .groovy/.jenkins for Jenkinsfile)

2) moved into a product specific folder (travisci/ci.yml, github/ for the issue and pull request templates)

3) use yet another top level file for indirection that is agreed upon (my initial thought is something named integrations.yml)

Re: Jenkins 2.0 Beta

#132

Post by empath75 »

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

the broken for loop functionally wasted an entire day for me because I didn't know if the problem was me or groovy or Jenkins, being unfamiliar with groovy.

Re: Jenkins 2.0 Beta

#133

Post by empath75 »

code_research wrote: post #123

Every random piece of software expects some kind of file in the root directory of a project - this is not acceptable and leads to messy project layouts. Could developers of these tools please stop dictating where people have to put the "Blahfile" dsl config files and finally allow people to configure these kind of details. Also I would like to propose a common standard directory "projectroot/config" for these kind of…

You don't need to call it Jenkinsfile. You can call it anything you want and put it anywhere you want.

Re: Jenkins 2.0 Beta

#134

Post by empath75 »

solipsism wrote: post #101
christop wrote: post #78

Earlier quoted context omitted.

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.

So don't use the Jenkins file. I have mine in a separate repo.

Re: Jenkins 2.0 Beta

#135

Post by Rezo »

oblio wrote: post #66
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…

TeamCity is cute, but at scale its pricing is... kind of bad. $12k for 50 agents. And it's not that hard to have 50 Jenkins slaves, especially if you're testing on multiple platforms or on different versions for those platforms.

If you have 50 Jenkins slaves, you probably have someone who's job is almost exclusively to babysit Jenkins. At my two previous workplaces, we had entire release teams focused on that, and still Jenkins was a never ending source of problems. And they did everything "right", all the Jenkins scripts and configs were in git etc.

$12K/month for a much (I mean, it's like going from cvs to git) better solution in that situation should be seriously evaluated; perhaps you could give every team in that org their own dashboards and eliminate/distribute the whole release engeering org. $12K/year, which is the actual TeamCity pricing, is a no-brainer, which unfortunately most teams are way too cheap to pay for, headcount looks so much better. Fortunately at least cloud based CIs are starting to seriously take off, hopefully I never have to deal with a home-grown Jenkins deployment again.

Re: Jenkins 2.0 Beta

#136

Post by slavik81 »

gtirloni wrote: post #99
jowiar wrote: post #37

Earlier quoted context omitted.

I'll believe it when I see it -- the Jenkins ecosystem is one of the worst offenders I've worked in with regards to things getting arbitrarily broken by a point release. I shudder to think what a major release will do.

We look at the list of available plugin updates and cringe. You never know if one plugin update will break something else, and then it's a game of downgrade/upgrade until things mostly work.

I don't update or install plug-ins without doing a taking a snapshot of the Jenkins machine. A new plug-in version may force various other plug-ins to update, and thereby break the many plug-ins that have incomplete dependency specifications.

I also found that downgrade may not fix the problem, as the upgrade may change your configuration files to use newer features, causing Jenkins to choke on them once downgraded.

Jenkins is a spiderweb of plug-ins held together by shoestring. It's a very useful tool, but extremely fragile.

Re: Jenkins 2.0 Beta

#137

Post by ebiester »

radicalbyte wrote: post #120
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…

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…

So, let's say you have 8 projects. In each of the 8 projects, you want to run the same static analysis tool. If the violations go up, you want an email sent out. If any critical errors are there, you want the build failed.

In any project, if the build fails, you want the latest commit automatically reverted.

Now, do you just copy and paste to each script, or do you have a chain of build processes and logic in the build system?

Re: Jenkins 2.0 Beta

#138

Post by hidingfornow »

quacker wrote: post #112
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.

I'm not in charge of writing the jobs, just standing it up and migrating a few dozen teams onto the system. Some are migrating from previous Jenkins systems, so the majority have old jobs in config.xml files. The Job Builder makes everything a little bit better, I've seen a few people using it already.

I'd still never use Jenkins on my own though, I'd just use Drone or pay CircleCI.

Re: Jenkins 2.0 Beta

#139

Post by nobleach »

mark242 wrote: post #22
FooBarWidget wrote: post #11

Earlier quoted context omitted.

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.

This is a horrible solution. No, my phone does NOT have that amount of memory available. It has it in its specs, but there's no way any ONE app should require that much. Look at what Jenkins is actually doing. Git/SVN checkout, build, other shell tasks. This should not take more than 16 megs!!! Let's be generous and add overhead for the GUI... so... 128mb. Java can certainly be tuned, but by default it wants a ton of memory.

Re: Jenkins 2.0 Beta

#140

Post by vito »

ipsi wrote: post #122
vito wrote: post #96

Earlier quoted context omitted.

@vito from the Concourse team here. We've recently started building standalone binaries which should lower the barrier to entry. Concourse itself has never been too tightly coupled to BOSH, it's just been the quickest feedback loop for us during development, so it ended up being the first thing we documented, primarily for internal use as we haven't really "launched" yet. Binaries are available for download in the Gi…

Does this mean it will be (is?) possible to deploy Concourse on a single machine without the headache of BOSH Lite? I've wanted to use Concourse, but when all you've got is a Mac Mini, doing a full BOSH deploy (or even BOSH Lite) is quite a big ask.

Yup (is). You'd just run `concourse web` and then `concourse worker` on the same machine. If all you have is a Mac Mini there's one gotcha, though: currently none of the resources will run on OS X, as they're built as Docker images. So you'll still need at least one Linux worker somewhere.

I think the next step from us may be to start building Vagrant boxes that just spin up a worker, parameterized with credentials to register with a Concourse `web` instance. That way you can run Concourse on OS X for iOS testing/etc. and still have all your resources and Linux containerization when you need it via a tiny local VM.

Post reply on HN