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

181–190 of 275 posts

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

#181

Post by thiht »

codethief wrote: post #165
hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

> 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

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

#182

Post by happymellon »

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…

> However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments.

When you say "automated tests" do you mean unit or integration tests, or both?

Because unit should generally be in your compilation process, not part of any image, and integration shouldn't require anything different in the image compared to any other environment.

Build it, which includes unit tests, and then deploy and integration tests should be run against your stable API.

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

#183

Post by hardwaresofton »

capableweb wrote: post #68
hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

> GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece As someone who only used GitLabs CI briefly when it initially launched, what hard parts did they innovate on exactly? As far as I could tell, it's a run-of-the-mill CI/CD platform, for better or worse, but nothing I'd call "innovative". But again, maybe since the first time I tried it when it launched, it has changed, and I missed somet…

Off the top of my head:

- Bring your own runner is easiest/most robust

- environment deploys and management

- tons of deployment integrations

- DevSecOps features

- Built in support ticket handling

- Free container & package registry

For most of these I’m pretty sure gitlab had them built into the platform (and free!) first

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

#184

Post by gonzo41 »

j1elo wrote: post #169
hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changi…

I agree with this, I recently had a pretty long network issue with our CI system and for the most part we just reran scripts or converted ci yml into scripts.

I like CI for secrets management, scrpted pipelines and deploying. And having one button do do all of that. But all the extra junk people do with it seems like another thing to have break.

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

#185

Post by hardwaresofton »

j1elo wrote: post #169
hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changi…

I definitely agree with and do this — it only falls apart when CI environment stuff interferes with file locations and other external state.

That said it is nice (if the scripts are simple) to do things like machine set up very easily.

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

#186

Post by hardwaresofton »

chologrande wrote: post #135
hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

How is Gitlab CI materially different from the jenkins model? I find that the only difference is that it's YAML - so even harder to debug, and maintains the same model where you must re run an entire pipeline every commit to test functionality.

Yeah YAML isn’t ideal, but I personally found jenkins to be terrible to configure, not super well documented, missing features compared to an installation of gitlab (ex built in registry).

Also the ability to rerun, target, and influence builds themselves is better on GitLab as well I think.

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

#187

Post by hardwaresofton »

tomjakubowski wrote: post #81
hardwaresofton wrote: post #55

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

Travis and Circle CI predated Gitlab, with YAML-configured workflows checked in to the repository and the ability to use custom images. GitlabCI's innovation was integration: making it a feature of repo hosting.

Yeah I didn’t say they innovated CI/CD — I said they innovated CI/CD as a platform-native offering!

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

#188

Post by anschwa »

happymellon wrote: post #182
anschwa wrote: post #108

Earlier quoted context omitted.

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…

> However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments. When you say "automated tests" do you mean unit or integration tests, or both? Because unit should generally be in your compilation process, not part of any image, and integration shouldn't require anything different in the image compared to any other environment. Build it, which inclu…

Great question! In my experience with ruby on rails, the application runtime is so dynamic, that even unit tests may not be reliable if run outside the production image.

I think normally this isn't much of an issue because other automated/manual integration testing in the staging environments will catch any major problems, to your point.

Another example would be for browser testing via chromedriver. I've usually seen this implemented along side unit tests (i.e., prior to the build phase) but since it generally serves as an integration level test for many applications, this has lead to issues due to the testing and production environments being out of sync.

I think multi-layer Docker images are a compelling solution to this, but it's not usually how I've seen it implemented.

Instead, I've typically seen that test and prod environments are manually maintained. Sometimes these are two separate Dockerfiles or some shared CI environment managed by different teams.

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

#189

Post by cvalka »

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)

https://docs.gitea.com/usage/actions/overview https://github.com/agola-io/agola https://github.com/concourse/concourse https://github.com/theSage21/jaypore_ci https://github.com/woodpecker-ci/woodpecker

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

#190

Post by chromatin »

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 understand staging and prod running the same executable, but wouldn't dev typically be a debug build?
Post reply on HN