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

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

twitchard.github.io

Post reply on HN
Print view View original

151–160 of 275 posts

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

#151

Post by fireflash38 »

awinter-py wrote: post #148

> Your editor won’t syntax highlight the Bash inside Groovy. You can’t run “shellcheck” (or any sort of Linter) on the Bash inside the groovy. You can’t very easily execute your shell commands to test them. this lands, and not specifically for jenkins. CI generally is inscrutable and difficult to test every CI has its quirk github CI feels fundamentally worse than gitlab because job artifacts are native in gitlab --…

One of the most frustrating things about gitlab ci is testing rules. There's just no way to do it without sending it live, especially for things that might be more rare (tags, releases, default branches, etc). Why that isn't a priority to let people see what the jobs/vars of a pipeline would be without filly executing it is beyond me.

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

#152

Post by maratc »

demizer wrote: post #35

Jenkins is rock solid. Been using it for three years to deliver highly critical software. The development experience is the worst of all ci tools since no one wants to setup jenkinspipelineunit to test the pipelines. Dagger might be the salvation here, but even that tool didn't support Jenkins out of the gate. And for those that are reading this, the statement about pipeline groovy being a trap is exactly right. Avoi…

> Avoid writing groovy at all costs. No one on the team wants to get good groovy and if you do, you're weird.

I guess I'm weird then, having produced about 100K LoC in Groovy over the last couple of years.

We'd move to Gitlab CI too — if it was anywhere near resembling a serious tool and not a sandbox toy collection.

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

#153

Post by mmcnl »

anschwa wrote: post #108
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 think it's common (and important!) to build your "production" image once and deploy it into a dev/staging environment first. This means there are no re-builds between deploys to each environment. However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments. This is challenging because you probably don't want to include any build/test related pack…

Why don't you want to include build/test related packages in your production image? Exactly because you mention you can't test the Docker image without these tools in the image, you cannot guarantee the production image works as you would expect it to work. Precisely because of that I think any packages that are required to run the tests should be part of the production image.

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

#154

Post by AceJohnny2 »

What would people recommend for a self-hosted CI system in 2023?

I'm currently leaning towards Jenkins, because neighboring teams are using it (with some pain due to their scale, but theirs is 10x-100x ours), and I have some ~10y-old experience with it.

(Our builds are compiling for embedded targets, with a Makefile-based system)

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

#155

Post by thayne »

The complaint about a long feedback loop is true of every CI system I've used (jenkins, travis, gitlab, github actions). None of them really have a good way to test a pipeline locally. The best solution here is to put as much of the build logic as possible in scripts and your build system.

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

#156

Post by AceJohnny2 »

AceJohnny2 wrote: post #154

What would people recommend for a self-hosted CI system in 2023? I'm currently leaning towards Jenkins, because neighboring teams are using it (with some pain due to their scale, but theirs is 10x-100x ours), and I have some ~10y-old experience with it. (Our builds are compiling for embedded targets, with a Makefile-based system)

I've noticed the Avahi folks use Woodpecker CI [1], which I hadn't heard of before, because it supports priorities and pre-emption [2]

[1] https://woodpecker-ci.org/

[2] https://social.treehouse.systems/@marcan/111258515328251078

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

#157

Post by kbenson »

AceJohnny2 wrote: post #154

What would people recommend for a self-hosted CI system in 2023? I'm currently leaning towards Jenkins, because neighboring teams are using it (with some pain due to their scale, but theirs is 10x-100x ours), and I have some ~10y-old experience with it. (Our builds are compiling for embedded targets, with a Makefile-based system)

Because not every company wants to allow their source code to the cloud. Basically all the reasons organization self host their code repositories (and a bunch do) all apply.

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

#158

Post by awinter-py »

fireflash38 wrote: post #151
awinter-py wrote: post #148

> Your editor won’t syntax highlight the Bash inside Groovy. You can’t run “shellcheck” (or any sort of Linter) on the Bash inside the groovy. You can’t very easily execute your shell commands to test them. this lands, and not specifically for jenkins. CI generally is inscrutable and difficult to test every CI has its quirk github CI feels fundamentally worse than gitlab because job artifacts are native in gitlab --…

One of the most frustrating things about gitlab ci is testing rules. There's just no way to do it without sending it live, especially for things that might be more rare (tags, releases, default branches, etc). Why that isn't a priority to let people see what the jobs/vars of a pipeline would be without filly executing it is beyond me.

yeah, really need a repl for CI. have run into exactly the same issue, conditional cases are impossible to test ahead of time

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

#159

Post by danielheath »

AceJohnny2 wrote: post #154

What would people recommend for a self-hosted CI system in 2023? I'm currently leaning towards Jenkins, because neighboring teams are using it (with some pain due to their scale, but theirs is 10x-100x ours), and I have some ~10y-old experience with it. (Our builds are compiling for embedded targets, with a Makefile-based system)

Buildkite is mixed-hosting; source code stays on your machines, on-prem if you like, but build logs / history / SCM triggers are hosted.

Unclear whether that’s enough for your situation but it’s by far my favourite because of how it lets you store the CI pipeline in the repository (so changes are reviewed via normal channels etc).

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

#160

Post by NameError »

dzhiurgis wrote: post #131
pharmakom wrote: post #85

Earlier quoted context omitted.

I find GitHub Actions incredibly counter-intuitive, personally.

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"
Post reply on HN