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

Jenkins Is Getting Old

itnext.io

Post reply on HN
Print view View original

161–170 of 340 posts

Re: Jenkins Is Getting Old

#161

Post by Cyph0n »

twunde wrote: post #112
Cyph0n wrote: post #42

Earlier quoted context omitted.

> GUI-oriented Not with pipeline files. I am a total Jenkins noob, but I was able to (relatively) quickly setup a minimal job that automatically pulls config from the relevant GH repo.

Ah yes, pipelines do make a difference in configuring jobs. However, how are you managing your plugins? Your Jenkins configs? Most likely those are manual (however if you've found a way that works well, please share). I've also found that for some functionality, I've had to add Groovy into my pipelines. That said, pipelines has made a HUGE difference. I still want to migrate but this fixes a large pain point.

Plugins and configuration are a given, but it’s something you do once upfront as part of the setup. Not sure how other tools handle this, though.

And yes, you do end up needing to use Groovy for anything non-trivial.

Re: Jenkins Is Getting Old

#162

Post by tterrace »

kalessin wrote: post #125
tterrace wrote: post #121

Earlier quoted context omitted.

I'm still on buildbot, but it's definitely showing its age and I'm hoping to move off of it within a year. I've been keeping an eye on Chromium's buildbot replacement, LUCI ( https://ci.chromium.org/ ). It's still light on documentation and the source is very internal google-y (they seem to have written their own version of virtualenv in go). However, based on the design docs it does look like they ran into a lot of…

Doesn't buildbot have dynamic workers implemented as latent workers? [1] What do you mean by underpowered buildbot steps? Are you implementing your own step classes? [1] https://docs.buildbot.net/current/manual/configuration/worke...

I'm not on buildbot nine (I think the new waterfall UI is a big regression), but what that is describing looks like a statically defined list of workers that scale up and down dynamically. What I'm looking for is the ability to add and remove workers at will, without having to add them to the configuration list and restart the master.

In terms of underpowered build steps, I have several fairly complicated, 1k-2k line build factories, with multiple codebases and hundreds of steps (some custom, some from the stdlib). There's many dependencies between the steps, and many different properties that can be toggled in the UI. All these steps need to be defined up-front in the master, but their actual execution often depends on runtime information, so it becomes a mess of doStepIfs. I think it would be an improvement to give a program on the worker the power to tell the service what it wants to do, rather than the other way around.

Re: Jenkins Is Getting Old

#163

Post by zbentley »

symlinkk wrote: post #155
kro92kfmrzz wrote: post #137

Earlier quoted context omitted.

We’re currently replacing Jenkins with EKS, and if it goes well, will consider doing the same with Circle. External partners have costs. And really the kind of things we need these things for here are pretty easy to configure in a Docker container. What we expect we’ll end up with after the Jenkins switch is Cloudformation templates we can hack into a Circle CI replacement. And we’d use GitLab if we could start over…

> replacing Jenkins with EKS This doesn't make sense to me. Jenkins is a CI tool - that means it can build, test, and deploy your code. EKS is a managed Kubernetes instance. That means it can run a collection of Docker containers. I don't see how EKS can accomplish building or testing.

Not the GP, but I suspect they may have been referring to replacing their use of Jenkins as a part-deployment, part-orchestration tool to administer lots of background jobs as a sort of a distributed cron. Many people use Jenkins thus, and in that domain Kubernetes does indeed compete along some axes.

Re: Jenkins Is Getting Old

#164

Post by outworlder »

humbleMouse wrote: post #86
outworlder wrote: post #50

Earlier quoted context omitted.

I wish I could bring you here to see you do better. Or do you mean systemic corporate problems? In that case, I agree. It still doesn't change the fact that Jenkins does not make my job any easier. I'll spend a day worrying about Jenkins idiosyncrasies ("why can't I use a pipe in sh", "why did my bash escaping disappear completely", "why 'dir' doesn't work with a container build agent?! (JENKINS-33510)", "why this in…

I feel you, but why are your jenkins pipelines so complicated? I feel like your workplace's deployable artifacts should follow a familiar pattern and there should not be much guessing/re-inventing the wheel with jenkins scripts. I feel like complicated builds are usually the result of an application that is not very well thought out in the first place.

> I feel you, but why are your jenkins pipelines so complicated?

You have an excellent point. Individual microservice containers are not complicated (then again, all they do is call a standardized script). The script will run a Dockerfile and push it to the registry. I would classify it as a 'trivial' Jenkins job, not even pipelines are used.

The pain starts when you want to do more than CI and try to get into CD. Or even worse, automate 'devops' tasks. That's where you run into all those warts.

A job could call Terraform, or spin up VMs, or run vacuum on a database, or any number of tasks. Or it may perform tasks on K8s to deploy a complex app. It may need to call APIs to figure out where to run things. And so on.

Since Jenkins is not only a CI/CD system, it can do anything, so people will try to make it do increasingly complicated stuff. And I'm arguing that this is wrong. If you have complex logic, it should be moved out of Jenkins so it can be more easily maintained and tested, and dependencies isolated. One of the easiest ways to do that is with containers. At which point, Jenkins loses most of its usefulness and other, newer tools shine.

Alternatively, use more specialized tools. If it is for CD, and Spinnaker works for you, please use that instead.

Re: Jenkins Is Getting Old

#165

Post by staffordrj »

exelius wrote: post #120
KaiserPro wrote: post #95

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

Agree in all cases. Bamboo was actually ok for a little while; but then they got rid of the cloud version which made it a bit more niche. I also like to plug VSTS in these conversations. It’s really nice to be able to drill down from feature roadmap to build status in a single tool without a lot of config. I haven’t built anything complex in it personally, but hear nothing but good things from the teams I work with w…

> but then they got rid of the self-hosted version

What do you mean by this? Is this not the self hosted version?

https://www.atlassian.com/software/bamboo/download

Re: Jenkins Is Getting Old

#166

Post by rmoriz »

bradrydzewski wrote: post #132
cjbprime wrote: post #96

It's true that Jenkins is old, and has systemic architecture problems which mean that I'm sure we haven't seen the last RCE for it. RCEs in build systems are a nightmare because build systems necessarily end up knowing secret tokens. But drone.io is no kind of replacement. It only works with Docker containers! Even small Jenkins installs can quickly end up with Windows targets, mobile builds, etc.

> It only works with Docker containers This will only be true for another week or two. We have devised a framework for alternate runtimes, including running pipelines directly on the host machine or in traditional virtual machines, that will be released end of week. Reference issue https://github.com/drone/drone/issues/2680

Does it support running on macOS and Windows, too? CI for native apps is IMHO the most common lock-in for Jenkins at the moment. Anything web or container related can almost always be implemented using pretty much any other CI/CD solution out there.

Re: Jenkins Is Getting Old

#167

Post by dboshardy »

badloginagain wrote: post #149
majkinetor wrote: post #130

Earlier quoted context omitted.

With newer versions you can include other yaml files. You can also have templates, special jobs starting with dot.

> With newer versions you can include other yaml files. Where do you see this? Looking at https://gitlab.com/gitlab-org/gitlab-ce/issues/18157 it seems this kind of support is still not started

https://docs.gitlab.com/ee/ci/yaml/#include

Re: Jenkins Is Getting Old

#169

Post by llamataboot »

Jenkins also routinely has massive security holes.

Last major exploit I heard about - the matrix.org exploit, was from privilege escalation through a Jenkins vulnerability [1]

[1] https://www.zdnet.com/article/matrix-hack-forces-servers-off...

--

This isn't nec a knock against Jenkins itself, but certainly a knock against thousands of orgs running their own unpatched Jenkins servers, often on the same machine as their other apps

Re: Jenkins Is Getting Old

#170

Post by Jedd »

core-questions wrote: post #138
badloginagain wrote: post #113

Earlier quoted context omitted.

GitLab CI is pretty good. I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_. What? I don't even... And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case. Sure as shit be…

> I hate, on a fundamental level this whole "bash in YAML" trend. This is why I hate Ansible. Looks simple until you need to do something complex, and then it becomes horrible. Chef's use of an actual language is far better, though on the flip side it's much harder to provide any kind of interface to configure it outside of a text editor. If only there were some language where config data and code were the same data…

> If only there were some language where config data and code were the same data structure. (hmmmmmm)

Do you perhaps mean syntax rather than structure? (Or a subset of the syntax.)

If I've guessed correctly, that language has already been wedged into lots of places that it's a poor fit, so I guess there's precedent there.

Post reply on HN