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

211–220 of 340 posts

Re: Jenkins Is Getting Old

#211

Post by ElFitz »

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…

AWS CDK seems nice

Re: Jenkins Is Getting Old

#212

Post by cmehdy »

mattbillenstein wrote: post #48
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…

Buildkite - run your own workers using their agent, they manage the ui, it's a pretty simple system. I use it for build and test automation and it's been pretty solid.

Have you observed any limitation or problem with it? I've been very interested in transforming our internal Jenkins CI into something lighter and modular with less maintenance which still allows multi-platform slaves, and BuildKite seems like a very interesting new player.

Re: Jenkins Is Getting Old

#213

Post by teacpde »

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)

Instantly reminds me of SICP and Lisp, code is data.

Re: Jenkins Is Getting Old

#214

Post by jayd16 »

qznc wrote: post #111
bovermyer wrote: post #8

The most interesting part of this is the very last paragraph. There really isn't a good self-hosted solution for build metadata/metrics, unless you write something yourself. It would be interesting to see a GUI dashboard for Drone/whatever builds and pipelines.

I never understood the purpose of dashboards. In the context of CI, I see three use cases and there is always a better solution than a dashboard. 1. Detect broken builds. It is better to actively notify somebody by mail, chat, whatever. 2. Prevent broken master. It is better to reject the pull request/patch before it becomes a problem. 3. Analyse the system. It is better to download the data and enable the use of wha…

Direct emails can't replace the collaborative "hey why are these still red" moments without spamming the whole team.

They can show non-event information such as build time trends at a glance.

Re: Jenkins Is Getting Old

#215

Post by unscaled »

Cyph0n wrote: post #161
twunde wrote: post #112

Earlier quoted context omitted.

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.

And then somebody needs a different, incompatible, version of plugin X and you set up another Jenkins master.

Or upgrade the the Jenkins master and watch other jobs fail.

And not to mention plugin Y and plugin Z crashing Jenkins when being run together because they share the same classpath.

While in the meantime one of the developer is trying to migrate his pipeline from one master to another and he finds out that of course they won't work because the plugins and configuration are not exactly the same.

This is exactly what OP was complaining about. You don't set up plugins and configuration just once. You want them to be replicable, but Jenkins does not provide a good way to do that.

Most other CI/CD system handle this issue very simply. They just don't have plugins, and have very little (if any) global configuration. This means you can start up an entirely new cluster and chances are your pipeline files will run without a hitch.

Re: Jenkins Is Getting Old

#217

Post by robrtsql »

deboflo wrote: post #191

AWS CodePipeline with CodeBuild supports GitHub webhooks, export artifacts between stages, many types of caching (S3 artifact caching, Docker caching, file/volume caching), Secrets Manager environment variable integration, queueing between stages, pipeline retries, stage retries, manual approval steps, integration with CloudWatch and many of services like Lambda, and provisioning all of the above via API, CLI, SDK, o…

> queueing between stages

Doesn't it only support a queue depth of 1 at each stage? Last I checked, if you have a change that is queued up waiting to get into a stage, and a newer change comes along, that newer change will supersede the old one. That makes CodePipeline only good for workflows where you only care about deploying the 'newest' of something.

I think the worst thing about CodePipeline is how hard they make it to run custom code from your pipeline. Your options are Lambda (limited to 15 minutes per run, or you have to rewrite your Lambda function to be called once every 30 seconds, essentially using the first run to start your deployment and every subsequent run to check to see if it's done yet or not) or CodePipeline Custom Actions (where you have to write the AWS SDK code for interacting with CodePipeline).

The AWS Developer Tools team could learn a thing or two from Azure Pipelines. They did it "right", IMO: you can create a 'bash' stage in your pipeline which runs whatever script you want from the build agent (which can either be hosted my Microsoft or hosted yourself). That's all I really want. CodePipeline could support that with a custom action but it's more stuff that I would have to set up.

Re: Jenkins Is Getting Old

#218

Post by mattbillenstein »

cmehdy wrote: post #212
mattbillenstein wrote: post #48

Earlier quoted context omitted.

Buildkite - run your own workers using their agent, they manage the ui, it's a pretty simple system. I use it for build and test automation and it's been pretty solid.

Have you observed any limitation or problem with it? I've been very interested in transforming our internal Jenkins CI into something lighter and modular with less maintenance which still allows multi-platform slaves, and BuildKite seems like a very interesting new player.

Not really - it's about as simple as buildbot with a nicer UI. All our builds trigger off of Github pushes - I have a handful of cheap Ubuntu VMs on Linode doing builds and tests for our code, and one Mac Mini doing builds for some developer tools - the latter is in a small rack in our office, but it works all the same.

Each build pipeline is just a small shell script which does some setup and runs make to build or invokes our test entry points.

Re: Jenkins Is Getting Old

#219

Post by Jedd »

mynegation wrote: post #189
Jedd wrote: post #170

Earlier quoted context omitted.

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

I am pretty sure Lisp was wedged into some places where it is a poor fit, but “lots”? Did you guess Javascript by any chance?

I did guess Javascript, as it happens.

Was I wrong? If it was meant to be a reference to Lisp, I take much of it back.

Re: Jenkins Is Getting Old

#220

Post by lsh »

stefan_ wrote: post #194
jensvdh wrote: post #134

Earlier quoted context omitted.

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

If it was only ugly. No, Jenkins UI is the dumpster fire that you would have gotten 20 years ago throwing a bunch of ActiveX components onto a VB panel. Like, let me just drag this Camera component to my snazzy program. Any one click can be a gateway into a one million miles deep rabbithole of unbridled mediocrity and brokenness.

You know, Drupal feels like this for me as well. We have Jenkins testing and deploying Drupal projects and it's like one of those cranes at the tip parked on top of a mound of garbage, shifting crap from one mound to another.
Post reply on HN