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

121–130 of 275 posts

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

#121

Post by hedora »

fullspectrumdev wrote: post #107
stickfigure wrote: post #82

Earlier quoted context omitted.

OP's company is paying for a dedicated CI team. Unless they have special needs, they probably aren't concerned about the CI hosting costs themselves.

I’ve worked at some places that were pretty huge, but the finance department absolutely fucking nickle and dime over everything . Even the smallest EC2 instances had to be accounted for with a business reason that they would accept, with audits happening every few days. Asking for a licence for something upfront was like pulling teeth.

I’ve encountered this too.

I always wonder why the eng departments never itemize the time they spend dealing with finance, then bill the finance team for the hours.

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

#122

Post by hedora »

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…

Multi-stage docker files mostly solve this problem:

https://docs.docker.com/build/building/multi-stage/

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

#123

Post by nullify88 »

AdrienPoupa wrote: post #86
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…

PHP dev here, we have extensions for development that make no sense in production, xdebug for example. You need it for breakpoints and debugging in general but it should not be installed in production. So we extend our production image and install it on top of it. Similarly, we include Composer (package manager) in the dev image only as we only need the installed dependencies in production but not the package manager…

In my experience, Xdebug absolutely made sense in production just not enabled by default for all requests. A lot of its functionality can be enabled via a cookie for a single session, and its made debugging production much easier as well as identifying bottlenecks in code or production infrastructure.

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

#124

Post by gjvc »

solardev wrote: post #59
runiq wrote: post #13

Earlier quoted context omitted.

> TeamCity Professional is free – even for commercial use – and has no limitations on features, number of users, or build time. Yeah, no. There's obviously gonna be a catch in the future.

To be fair, I've never seen a company turn around a licensing fiasco as well as Jetbrains did. Initial announcement, 2015: https://blog.jetbrains.com/blog/2015/09/03/introducing-jetbr... Community anger a couple days later: https://bytecrafter.blogspot.com/2015/09/how-jetbrains-lost-... Significant changes after hearing the feedback, a couple weeks later: https://blog.jetbrains.com/blog/2015/09/18/final-update-on-t..…

To be fair, I've never seen a company turn around a licensing fiasco as well as Jetbrains did.

Absolutely, though it was quite dramatic.

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

#125

Post by mkesper »

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…

But then there have to be rebuilds, no?

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

#127

Post by roland35 »

john-tells-all wrote: post #66
zdw wrote: post #16

All of the test runners have their issues. I've had as much problems with Jenkins as I've had with Github Runners and similar solutions. The best way out of this is to subdivide responsibilities: - Put all build/publish/test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well. The only interaction between a test runner and the codebase should be running `make `. - Put all permis…

> - Put all build/publish/test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well. This is critical! In many teams Devs are "lazy", if any errors or weirdness happens in CI they just wave their hands and say "not a feature, not my problem". Even though they know exactly what's in the test code, the deploy code, and can see the issue. Letting Devs see and run the CI scripts loca…

It also takes a lot less time to fix the tests locally too - rather than tweak it... push the change... oops it failed again... repeat...

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

#128

Post by AdrienPoupa »

nullify88 wrote: post #123
AdrienPoupa wrote: post #86

Earlier quoted context omitted.

PHP dev here, we have extensions for development that make no sense in production, xdebug for example. You need it for breakpoints and debugging in general but it should not be installed in production. So we extend our production image and install it on top of it. Similarly, we include Composer (package manager) in the dev image only as we only need the installed dependencies in production but not the package manager…

In my experience, Xdebug absolutely made sense in production just not enabled by default for all requests. A lot of its functionality can be enabled via a cookie for a single session, and its made debugging production much easier as well as identifying bottlenecks in code or production infrastructure.

That's certainly possible but we have other tools for that such as NewRelic that served us well.

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

#129

Post by IshKebab »

xp84 wrote: post #24
anon23432343 wrote: post #9

Jenkins works... No it dosen't or maybe it does for java which I don't care about. The ui looks like from the 90s. Finding anything in bigger projects/companies is impossible... I have browser bookmarks to find anything. The log view is annoying at best. I have nothing good to say about jenkins, it feels like it is stuck in the 2000s and refuses to change.

The 90s were the last actual advance in UI design anyway. Design has drifted in a terrible direction, in the past decade or two especially. Some of this is justified (by some) by optimizing for mobile, but that’s precisely the kind of thing I wouldn’t want creeping into my CI tooling anyway. I don’t do that on a phone.

For desktop apps maybe. Not for websites though. Jenkins has an absolutely objectively terrible UI. Super ugly, inconsistent and incomprehensible.

I've used Buildbot, Travis, Gitlab, GitHub and Teamcity. None of them are anywhere near as bad as Jenkins. Even Buildbot has a much much saner UI and that's a weird Python CI system that practically nobody uses.

Jenkins is just an objectively terrible choice.

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

#130

Post by maratc »

i386 wrote: post #79
troupo wrote: post #37

Earlier quoted context omitted.

Jenkins BlueOcean is one of the best "fancy UIs"

Thanks! My team and I made that and it was a lot of fun :)

Thanks for that, we use it all day every day!

It's too bad it's been declared "end of life", without any replacement in sight, and nobody these days is fixing some bugs that are really bothering us sometimes...

Post reply on HN