The worst thing about Jenkins is that it works (2019) • Hacker News Board

Re: The worst thing about Jenkins is that it works (2019)

#231

Post by never_inline » Mon, Dec 04, 2023, 12:14 PM UTC

twunde wrote: post #100

happymellon wrote: post #53

Interesting, the side snipe about Docker > One of the mostly-false promises of Docker, as it was sold to me by the true believers who introduced me to it, was that, if you do it right, you can run the same docker image, and therefore have basically the same environment in production, in CI, and on your local development machine. I literally have never worked anywhere that hasn't used the same container in dev/test/pr…

I'm general, it's an anti pattern since it's makes everything much more complicated. The typical reason to have it is so that there are dev tools in the dev container (autoformatter, linter etc) or support for hot reloading and then the prod container is locked down. The other pattern you'll sometimes see is that the prod container will include an agent or a certificate bundle, although it's more common to use sideca…

> It becomes problematic because it then becomes easy for engineers to have a completely different container for dev then is used for prod

If the differences between dev and prod are also programmatic in nature (eg based on flag, and mostly configuration-like values), it should be fine.

Re: The worst thing about Jenkins is that it works (2019)

#232

Post by tcangussu » Mon, Dec 04, 2023, 12:15 PM UTC

zzyzxd wrote: post #219

dig1 wrote: post #20

Jenkins is not perfect by any means, but I can say it is much better than existing solutions (taking pros and cons after trying and using many of them). Sure, it doesn't have fancy UI or flying buttons, nor is it rust/PWA/react/whatever-rage-is-these-days, but it does its job - it works, is free, and has been very well-maintained for ages. Download a single file and run it. Want to extend it? There is a plugin for ev…

> There is a plugin for everything under the sun Yeah, that's the biggest problem. Almost every thing you need for a CI system comes in the format of a plugin, because Jenkins core is too simple. You can't always say no to your developers' plugin requests, because many of them are actually very reasonable. Now you install one simple plugin, and it comes with 10 dependency plugins, and that's when your nightmare begin…

You can use jcasc (Jenkins configuration as code) with regular shell jobs, or Jenkins Job Builder, to name two alternatives "in between".

Re: The worst thing about Jenkins is that it works (2019)

#233

Post by codethief » Mon, Dec 04, 2023, 12:29 PM UTC

thiht wrote: post #181

codethief wrote: post #165

Earlier quoted context omitted.

> Gitlab CI is still the best CI in the game IMO, Oh god, if this is the best CI in the game, I don't want to be part of this game anymore. I work with (as in write pipeline code for) Gitlab CI almost every day and it's absolutely horrible. Not only does YAML lack any type safety whatsoever, but every day I run into yet another open ticket in the Gitlab issue tracker because using a declarative (YAML-based) approach…

That’s not my experience at all. You do know you can run arbitrary shell scripts, and that means they don’t need to think of every possible use case? If your CI process is so complex that YAML + arbitrary code doesn’t work, you might want to get that checked, it’s not normal

Random example:

I want to define a setup job to build & push a base Docker image to our container registry. I then want to use this image as IMAGE in all subsequent jobs. This is impossible because the IMAGE field in YAML cannot be dynamic (determined at runtime) but I'd like to version/tag my image using the $CI_COMMIT_SHA.

Re: The worst thing about Jenkins is that it works (2019)

#234

Post by codethief » Mon, Dec 04, 2023, 12:34 PM UTC

devopseng85 wrote: post #223

codethief wrote: post #165

Earlier quoted context omitted.

> Gitlab CI is still the best CI in the game IMO, Oh god, if this is the best CI in the game, I don't want to be part of this game anymore. I work with (as in write pipeline code for) Gitlab CI almost every day and it's absolutely horrible. Not only does YAML lack any type safety whatsoever, but every day I run into yet another open ticket in the Gitlab issue tracker because using a declarative (YAML-based) approach…

I am surprised to hear this as well. We had Jenkins in my previous gig. It worked, but I spend all my time keeping it humming and learnt nothing else. In my current gig, we were a Drone shop. We switched to Harness CI enterprise and it’s worked really well for us. Their hosted builds are pretty speedy! We did evaluate Gitlab CI but went with Drone. Gitlab CI is not a top 5 CI vendor IMO.

I'm not following. You're surprised to hear complaints about Gitlab, even though you're not actually using Gitlab (in fact, you say "Gitlab CI is not a top 5 CI vendor IMO") and you are praising a completely different product (Harness CI)?

Re: The worst thing about Jenkins is that it works (2019)

#235

Post by voytec » Mon, Dec 04, 2023, 12:36 PM UTC

NameError wrote: post #160

dzhiurgis wrote: post #131

Earlier quoted context omitted.

It’s the confusion between actions(basically third party plugins) and workflows(the ci that you are building for yourself) that got me.

I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system. It's really natural to say something like "we need a push action for this repo" when it might be more correct to say "a push workflow"

> I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system.

You're right:

- product is called GitHub Actions

- your workflow (consisting of jobs and steps) is a workflow

- 3rd party workflow included in yours is an action, not workflow though

- I more often hear engineers refer to workflows as actions

But there are more annoying decisions

- (org-wide) required workflows being recently deprecated

- the feature was buggy (ie used alongside org-wide branch rules)

- but could have been fixed, not deprecated

- some kind of "marketplace" (with reviews, developers trust levels etc) for modular/pluggable actions (workflows) would be welcome; currently it's a "1st solution fitting the problem used" mess with little to no standarisation

- I find the necessity to write a step cloning the repo from which a workflow is running ridiculous - it should be at most a single configuration line somewhere at the top of a workflow

Re: The worst thing about Jenkins is that it works (2019)

#236

Post by nijave » Mon, Dec 04, 2023, 1:04 PM UTC

codethief wrote: post #233

thiht wrote: post #181

Earlier quoted context omitted.

That’s not my experience at all. You do know you can run arbitrary shell scripts, and that means they don’t need to think of every possible use case? If your CI process is so complex that YAML + arbitrary code doesn’t work, you might want to get that checked, it’s not normal

Random example: I want to define a setup job to build & push a base Docker image to our container registry. I then want to use this image as IMAGE in all subsequent jobs. This is impossible because the IMAGE field in YAML cannot be dynamic (determined at runtime) but I'd like to version/tag my image using the $CI_COMMIT_SHA.

Can't you use build time variables for this? https://docs.gitlab.com/ee/ci/variables/#pass-an-environment...

Re: The worst thing about Jenkins is that it works (2019)

#237

Post by vel0city » Mon, Dec 04, 2023, 1:22 PM UTC

voytec wrote: post #235

NameError wrote: post #160

Earlier quoted context omitted.

I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system. It's really natural to say something like "we need a push action for this repo" when it might be more correct to say "a push workflow"

> I think it was a mistake for Github to name the whole product "Actions" and then re-use the same word for a specific component within system. You're right: - product is called GitHub Actions - your workflow (consisting of jobs and steps) is a workflow - 3rd party workflow included in yours is an action, not workflow though - I more often hear engineers refer to workflows as actions But there are more annoying decis…

> 3rd party workflow included in yours is an action, not workflow though

Not entirely accurate. You can use reusable workflows from third parties and you can use actions from third parties. It being a third party's doesn't mean it's an action. Also, you can make your own actions, it doesn't need to be a third party's.

Just to add to the naming confusion.

Re: The worst thing about Jenkins is that it works (2019)

#238

Post by hwc » Mon, Dec 04, 2023, 1:23 PM UTC

I agree with most of this. I end up with a lot of

      sh 'make all'
      sh 'make test'

In my `Jenkinsfile`, but there's not a great way to test things locally.

Re: The worst thing about Jenkins is that it works (2019)

#239

Post by JeremyNT » Mon, Dec 04, 2023, 1:32 PM UTC

codethief wrote: post #233

thiht wrote: post #181

Earlier quoted context omitted.

That’s not my experience at all. You do know you can run arbitrary shell scripts, and that means they don’t need to think of every possible use case? If your CI process is so complex that YAML + arbitrary code doesn’t work, you might want to get that checked, it’s not normal

Random example: I want to define a setup job to build & push a base Docker image to our container registry. I then want to use this image as IMAGE in all subsequent jobs. This is impossible because the IMAGE field in YAML cannot be dynamic (determined at runtime) but I'd like to version/tag my image using the $CI_COMMIT_SHA.

This is definitely possible. We've been building an image in one phase and then running it in subsequent phases for years with gitlab.

I think you are going about this wrong. Are you generating an image tag dynamically? When you are tagging the image, make sure that you generate the tag deterministically based on information that is available to gitlab when the pipeline is created.

So for example, you could use the tag foo:$PIPELINE_ID instead of foo:$random

Re: The worst thing about Jenkins is that it works (2019)

#240

Post by dangus » Mon, Dec 04, 2023, 5:04 PM UTC

Scramblejams wrote: post #198

dangus wrote: post #96

Earlier quoted context omitted.

I don’t think the issue with Jenkins is the lack of bells and whistles. The UI it has is unintuitive - I always feel like I can’t find what I’m looking for anytime I am in there. It has two different UIs (last I checked) which is kind of insane, blue ocean still sucked the last time I used it and the product can’t 100% move away from the old UI (again, last I checked…) On top of all that it’s not really fun to admini…

And Blue Ocean’s effectively deprecated!

Wow. I mean, you're joking right? No? Wow.

That furthers my belief that Jenkins is the quintissential mediocre open source project that only hangs on to life because it's free (and maybe just becasuse it's free as in beer).

If I ran a department and I was given an unlmited CI budget forever I can't see what would compel me to use Jenkins.