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

201–210 of 340 posts

Re: Jenkins Is Getting Old

#201

Post by jhanschoo »

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. Let's take a powerful, turing complete language and put it in a _config file_.

That's a feature. You don't want to reason in Turing languages, you want to reason in a mostly restricted grammar with its Turing-complete escape hatches clearly pointed out.

Re: Jenkins Is Getting Old

#202

Post by _vuqm »

FrenchyJiby wrote: post #18

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…

We run our infrastructure off of cloudflare, so we can easily spin up a staging environment that's an exact replica of production (only difference is # and size of instances). We also run a staging jenkins server that's defined in the cloudflare config.

We keep our jenkins jobs version controlled by checking in each job's config.xml into a git repo. In the past I've seen the config.xml files managed by puppet or other config management tools.

This helps us get around the "hard to backup" and "test in production" issues. We can test out jenkins changes in staging, commit those changes to our jenkins repo, and then push up the config.xml file to the production jenkins server when we're ready to deploy.

Re: Jenkins Is Getting Old

#204

Post by inferiorhuman »

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…

I'll take writing stuff in YAML (Ansible) over all of the complexities and performance issues Chef brings. At megacorp a lot of my peers still hadn't let go of the button pusher mentality and were both inexperienced at coding and skeptical of automation. The problem with the power of ruby (as Chef exposes it) is that you've got the power of ruby aimed right at your foot.

On top of it, using ruby was a big pain when trying to work with rvm (e.g. for deploying ruby apps or developing ruby apps and running chef commands locally). Things may have gotten better since I last suffered through Chef, but we started running towards terraform + cloudformation.

Re: Jenkins Is Getting Old

#205

Post by lstamour »

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.

Kubernetes orchestrates running jobs, giving them all required prerequisites and data in the form of Docker containers and can record or report logs, as well as store configuration and secrets. Jenkins orchestrates Jenkins agents running jobs on pre-configured servers, stores configuration and secrets, and records and archives logs and built files. They are both very similar from this perspective. There’s no reason Jenkins couldn’t attach a monitoring system to run a Jenkins job when a service goes down or exceeds capacity. And you probably would prefer storing secrets and files off your Jenkins server if your builds are distributed or you run out of space. Basically... Jenkins is an orchestration service but most people run short-lived tasks with it, and they have to worry about configuring and deploying Jenkins agent images separately.

Re: Jenkins Is Getting Old

#206

Post by nhumrich »

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…

Gitlab lets you run any step with a different docker base image. How about instead of bash scripting in the yaml, you just put scripts, in any language, in a docket file, and simply use bash to call those scripts. The gitlab yaml is not designed for you to code in, bash is just a standard interface for calling into other things.

Re: Jenkins Is Getting Old

#207

Post by draw_down »

jennbriden wrote: post #142

Hello, I see a lot of great feedback in this post. I am a product manager working at CloudBees, the primary corporate sponsor of Jenkins. Jenkins is now in the Continuous Delivery Foundation as well. While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part o…

Those comments are also written by people. People who get frustrated when their tools don't work as they expect, mislead them in certain regards, cause them more consternation and confusion than seems necessary. (Feel free to caveat the preceding sentence with "as they see it", as you see fit.)

It would be great if everything worked as we expected, and it would also be great if people reacted to things not working as they expect with Vulcan rationality, but that's not the world we live in. Empathy runs in many directions, and the people who perceive their tools as impeding progress rather than abetting it deserve it too.

It is my hope that your perception of "a lot of great feedback" is genuine.

Re: Jenkins Is Getting Old

#208

Post by jayd16 »

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…

Is there something in gitlab that can give you same type of node, job, pipeline and trend information in a dashboard like jenkins can?

Re: Jenkins Is Getting Old

#209

Post by sytse »

jniedrauer wrote: post #146
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…

Do you self-host gitlab? I'd definitely consider moving but it would also mean moving my source control.

If you are on GitHub you can use GitLab CI with that https://about.gitlab.com/solutions/github/

Re: Jenkins Is Getting Old

#210

Post by sytse »

frozenice wrote: post #87
user5994461 wrote: post #52

Earlier quoted context omitted.

TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…

+1 for TeamCity. We tried GitLab CI before, but are happier with TeamCity now.

What can we do better in GitLab?
Post reply on HN