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

71–80 of 275 posts

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

#71

Post by dijksterhuis »

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…

It’s possible to do ‘uses’ on GitLab, but there’s a few extras needed admittedly (branch name and path to file)

    include: https://gitlab.com/awesome-project/raw/main/.before-script-template.yml
https://docs.gitlab.com/ee/ci/yaml/includes.html#include-a-s...

But I agree, the social virality is what makes GitHub Actions what it is.

I used to only visit a GL project when I needed to look through Nvidia cuda container builds… everything else I needed was on GH :shrugs:

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

#72

Post by theptip »

> The head of SRE championed Gitlab CI. I resisted this idea because I, the relatively inexperienced manager of a nascent team, was daunted by the prospect of trying to supplant Jenkins, Github, and JIRA all at once.

I think this is a really big scoping mistake. There is a clean glide path, and I have no idea why you'd think you need to replace Jira.

You can use Gitlab Runners in Github (https://docs.gitlab.com/ee/user/project/integrations/github....). Then with your mirrored repo you can try out the Gitlab features and realize it's better to use Gitlab for your repo if you're aso using it for CI. Having switched back and forth over the years (with tens of engineers using the repos), it's really not a lot of work to migrate between Github and Gitlab.

Finally, if you like Jira, just use that? Sure there are advantages to having everything in one place, but if you're already using Jira+Github then you'll get an equivalent experience with Jira+Gitlab.

I think this is one of those things that if you had actually prototyped the migration, you would find that it's much easier than you thought it was going to be.

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

#73

Post by trilbyglens »

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…

Currently working on a gitlab api thing for work, and I gotta say their API us a complete joke. GitHub runs laps around them in this area. Gitlab is actually worse than bitbucket, believe it or not.

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

#76

Post by ebiester »

theptip wrote: post #72

> The head of SRE championed Gitlab CI. I resisted this idea because I, the relatively inexperienced manager of a nascent team, was daunted by the prospect of trying to supplant Jenkins, Github, and JIRA all at once. I think this is a really big scoping mistake. There is a clean glide path, and I have no idea why you'd think you need to replace Jira. You can use Gitlab Runners in Github ( https://docs.gitlab.com/ee/u…

Gitlab is 29/month. It’s hard to stomach 29 + the money for GitHub and Jira, depending on the features you need. (Minimum 11/mo)

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

#77

Post by zdw »

sevagh wrote: post #58
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. The only interaction between a test runner and the codebase should be running `make `. This always breaks because then each platform has a specific way of defining env vars or secrets for those Makefiles and bash scripts. End result is devs still can't really run CI "proper" the way it's configure…

This is fundamentally an interface problem. As you called out Env vars are a pretty common and well supported interface, across multiple platforms.

Do you have a better option to suggest?

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

#78

Post by dijksterhuis »

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…

> People who have had to deal with processes that rebuilt images for each environment, can you tell me what was different in each image?

Tensorflow used to generate multiple images for different use cases: cpu only, GPU, cpu with Jupyterhub, GPU with Jupyterhub.

So each release would generate minimum 4x container builds.

CPU only images were useful for local testing of ml code at CLI (does it run) when a GPU might no be available.

Jupyterhub variants for simple GUI for development work.

GPU for obvious reasons (run the damn thing).

I can’t remember if they used to do builds for their release against multiple CUDA / CuDNN versions… that might have been PyTorch.

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

#79

Post by i386 »

troupo wrote: post #37
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…

Jenkins BlueOcean is one of the best "fancy UIs"

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

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

#80

Post by jurassic »

Having worked with a huge Jenkins deployment at a large company somewhat recently (>10,000 jobs), I found it worked okay enough that company leadership never felt it was worth the pain if switching. But all the friction points added up to a system that was rarely touched by anyone who hadn’t learned where all the bodies were buried. Over time that meant as an engineering org we were underinvesting in CI; there was a lot of quality-oriented stuff beyond unit testing that never got implemented in CI because the typical dev was unaware of how to change it or fearful about trying to change it. The relative accessibility of Github Actions (and other config as code alternatives) transforms the average dev’s relationship to CI from consumer to owner/developer/maintainer, and I think that is extremely worthwhile even if these tools bring some new problems of their own.
Post reply on HN