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

131–140 of 340 posts

Re: Jenkins Is Getting Old

#131

Post by michaelneale »

Co-founder of cloudbees here, just some corrections:

1) there are (since 1 year) restartable builds/stages in open source (a bit over a year IIRC) - when the article mentions that they are not in open source.

2) Jenkins X is something VERY DIFFERENT from Jenkins (despite the name), it is "master less", yes requires a kube cluster to power it, but it has no Jenkins instances as you know it, in a lot of ways quite a bit different as it uses Tekton as the engine for running pipelines (which has a bunch of advantages). So I wouldn't group it in with the same challenges and constraints. It is something new that shares a name and some of the ideas.

Jenkins, along with Spinnaker and Tekton and Jenkins X are now part of https://cd.foundation - worth a look to see how they are evolving (expect some changes).

Re: Jenkins Is Getting Old

#132

Post by bradrydzewski »

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

Re: Jenkins Is Getting Old

#133

Post by majkinetor »

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…

Gitlab is awesome, its impressive what you get for free. Runners are nice, can run in powershell, bash, docker, vm , you name it.

The main problem with runner is that you cant easily execute build script on the host. Exec command isn't very useful and AFAIK deprecated.

Re: Jenkins Is Getting Old

#134

Post by jensvdh »

fizwhiz wrote: post #129
StevePerkins wrote: post #124

Earlier quoted context omitted.

> " ... has an offensive UI... " > " ... suck massive genitals... " I cannot believe that this is the top-voted comment.

I assumed OP felt that the background UI's fictional butler (a metaphor) is what offended them so I asked why this was the case. Many downvotes ensued.

Pretty sure they meant the UI is so ugly it's offensive.

Re: Jenkins Is Getting Old

#135

Post by 2StepsOutOfLine »

Tangentally I've had great success with Drone. Holding similar frustrations that other commenters are expressing here it was a breath of fresh air to see how dead simple making custom steps in Drone was compared to actually needing to write code for Jenkins.

Every step in Drone is just a container, so if I want a Golang build container I can just set the step image to Golang:latest and start running build commands. And if you're wanting to encapsulate some logic into a "plugin" you can just pre-make your own docker image and from there any settings you pass in with the steps are converted to environment variables that can be accessed inside the container. Many of the default drone plugins like docker registry build, etc. Are just a couple line bash scripts on GitHub.

Re: Jenkins Is Getting Old

#136

Post by yRetsyM »

chinhodado wrote: post #89
hardwaresofton wrote: post #9

Disclaimer: I'm pretty biased towards Gitlab -- write about the things you can do it from time to time and they gave me some free swag once. Best CI I've ever used is Gitlab CI[0]. The runner is completely open source[1] and you can use your own runner with your gitlab.com (or local instance) projects -- set it up in an autoscaling group[2] for savings. I run https://runnerrental.club but Gitlab also recently release…

Last I checked, there were a lot of little things that made it not possible to move to GitLab CI. E.g.: - Can't customize your git checkout process (e.g. shallow clone with depth, or merging source branch with target branch with certain strategy) - Can't make job run/not run based on filter on source branch/target branch/etc. of a merge request - Can't dynamically make certain jobs only run on certain agent machines…

You can definitely do all of your requirements, but likely as a result of recent features

1) you can customise the git checkout depth and style: https://docs.gitlab.com/ee/ci/yaml/#shallow-cloning https://docs.gitlab.com/ee/ci/yaml/#git-strategy

2) https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic

3) https://docs.gitlab.com/ee/ci/yaml/#tags

I'm not associated with gitlab at all but happy to give pointers if anyone wants to contact me direct

Re: Jenkins Is Getting Old

#137

Post by kro92kfmrzz »

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…

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 there but are bought into some end user tools and workflows that connect to GitHub that people don’t want to give up. BUT no one cares about Jenkins going away since they use it through a Slack bot ️

Re: Jenkins Is Getting Old

#138

Post by core-questions »

badloginagain wrote: post #113
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…

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 structure. (hmmmmmm)

Re: Jenkins Is Getting Old

#139

Post by lmm »

AnthonBerg wrote: post #127
lmm wrote: post #115

Earlier quoted context omitted.

TeamCity doesn't handle downstream builds properly. Bamboo has severe stability problems. I've worked at places that evaluated them and always found Jenkins was still the least bad option.

Could I ask you to elaborate on the downstream build issues? Thanks!

We had the problem that whenever we built a project it would trigger builds of any project that transitively depended on that module. So if you have e.g. 26 projects depending on each other in a line and you make a change to the first one, in jenkins this will run 26 builds as it builds A, then B, then C, .... . Whereas in Teamcity it will run 26 + 25 + 24 + ... builds: it'll build A, then B-Z immediately, then the build of B will trigger another build of C-Z, then the build of C will trigger a rebuild of D-Z and so on.
Post reply on HN