Live data from Hacker News

Jenkins Is Getting Old

itnext.io

111–120 of 340 posts

Re: Jenkins Is Getting Old

#111

The most interesting part of this is the very last paragraph. There really isn't a good self-hosted solution for build metadata/metrics, unless you write something yourself. It would be interesting to see a GUI dashboard for Drone/whatever builds and pipelines.

I never understood the purpose of dashboards. In the context of CI, I see three use cases and there is always a better solution than a dashboard.

1. Detect broken builds. It is better to actively notify somebody by mail, chat, whatever.

2. Prevent broken master. It is better to reject the pull request/patch before it becomes a problem.

3. Analyse the system. It is better to download the data and enable the use of whatever analysis tools are suitable.

Re: Jenkins Is Getting Old

#112
post #42

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…

> GUI-oriented Not with pipeline files. I am a total Jenkins noob, but I was able to (relatively) quickly setup a minimal job that automatically pulls config from the relevant GH repo.

Ah yes, pipelines do make a difference in configuring jobs. However, how are you managing your plugins? Your Jenkins configs? Most likely those are manual (however if you've found a way that works well, please share). I've also found that for some functionality, I've had to add Groovy into my pipelines.

That said, pipelines has made a HUGE difference. I still want to migrate but this fixes a large pain point.

Re: Jenkins Is Getting Old

#113

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

GitLab CI is pretty good.

I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_.

What? I don't even...

And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case.

Sure as shit better than Jenkins though.

Re: Jenkins Is Getting Old

#114

Trying to integrate Jenkins w/ Github Enterprise proved to be a real pain for me. It wasn't clear what git* plugin is the best to use for how I wanted to setup builds. It's literally impossible to deploy Jenkins in a repeatable manner with just configuration files, you must get it online and use the api to configure such simple things as API keys (eg, specify the ID of the key so your jobs actually reference the key…

You definitely can configure Jenkins in a repeatable manor. See https://wiki.jenkins.io/display/JENKINS/Groovy+Hook+Script

You can write all the configuration in groovy and it will execute when the Jenkins process starts up.

There is also "Jenkins Configuration as Code" plugin which allows you to have a single yaml file to configure most of the Jenkins system.

https://github.com/jenkinsci/configuration-as-code-plugin/bl...

Re: Jenkins Is Getting Old

#115

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…

TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…

TeamCity doesn't handle downstream builds properly. Bamboo has severe stability problems. I've worked at places that evaluated them and always found Jenkins was still the least bad option.

Re: Jenkins Is Getting Old

#116

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

GitLab CI is pretty good. I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_. What? I don't even... And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case. Sure as shit be…

You could use a build system to build .gitlab-ci.yml from many source configuration files, and a build system to build the configuration for the build system that builds the configuration for your build system, and...

Re: Jenkins Is Getting Old

#117

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…

Check Codefresh (I work for them)

https://codefresh.io/continuous-deployment/codefresh-versus-...

https://codefresh.io/continuous-integration/using-codefresh-...

Re: Jenkins Is Getting Old

#119

Jenkins-X is really cool. I love how you can group services together into an environment and deploy that to a single Kubernetes namespace, and how well it uses github releases. I really hope Gitlab's Auto-Devops team is looking at it closely and stealing all the great ideas it has because that's what our team is using.

Jenkins X requires Kubernetes and Helm. Not all companies are deploying like this.

(I work for Codefresh, a competitor of Jenkins X)

Re: Jenkins Is Getting Old

#120

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

Agree in all cases. Bamboo was actually ok for a little while; but then they got rid of the cloud version which made it a bit more niche.

I also like to plug VSTS in these conversations. It’s really nice to be able to drill down from feature roadmap to build status in a single tool without a lot of config. I haven’t built anything complex in it personally, but hear nothing but good things from the teams I work with who do.

Edit: looks like I had the bamboo thing backwards; but I remember I stopped using it for a reason :)

Post reply on HN