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

Shifting Gears

jenkins.io

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Shifting Gears

#101

Post by baylisscg »

dominotw wrote: post #78
jacques_chester wrote: post #70

Earlier quoted context omitted.

The deeper issue with plugins is that they create global state across everything . Switching the execution engine to Kubernetes will help a lot with operational pain. But consider the comparison to Concourse, which also predates Kubernetes. What drove Concourse into being wasn't the lack of Kubernetes (being born during the Diego project, itself a container scheduler), it was the amount of time and pain and unsafety…

I soon as I saw the word concourse, I look at the username, sure enough it was you. You bring up Concourse comparision every single jenkins thread. I've considered it the past but looked like there is almost no adoption outside pivotal. would you say the adoption increasing in 2018, I would like to give it another spin if possible.

We looked at it. It was our second choice. Ultimately, its entirely self-hosted nature was it's greatest strength and weakness. We like self-hosting but don't have the resources to get it going at the moment. It's interesting enough that we'll keep revisiting it.

Re: Shifting Gears

#102

Post by zmmmmm »

honkycat wrote: post #27

The worst part of my job is configuring our Jenkins server and managing builds in their dumbass groovy based DSL. I'm willing to bet that most people just want to build GitHub repos. Then why do we have to do this mess to get a decently repeatable deployment strategy: https://coderanger.net/jenkins/ I should not have to crack open plugin source code in order to configure the plugin programmatically. It's dumb and bad…

> Also groovy is a bag language.

This seems to be a repeated pattern that is really giving Groovy a bad reputation: it keeps getting embedded as an extension point / scripting solution inside other products. It is sold as "it's almost the same as Java, so we don't need any documentation for it" - and the result is that people with little to no Groovy knowledge end up trying to use it and get incredibly frustrated with it.

I'm curious if your conclusion above is based only on encountering it inside other things (Gradle,Jenkins, etc) or if it's actually from analysing its characteristics as a language more generically?

(FWIW, Groovy is probably my favorite language, but I use it as a full stack language for application development, quite a different mode to how most other people encounter it).

Re: Shifting Gears

#103

Post by yebyen »

michaelneale wrote: post #95
jacques_chester wrote: post #82

Earlier quoted context omitted.

> Honestly I don't understand this about "making a version of Jenkins that runs well on Kubernetes" – this is the _only way_ I have ever run Jenkins, and I think it runs already extraordinarily well for our purposes. I think the idea is not that Jenkins runs on Kubernetes, which as you note can already be done. It's rather that Jenkins uses Kubernetes as a replacement for the worker infrastructure.

yes that is right I believe.

This can be done with plugins, kubernetes-plugin for example. I'm looking forward to seeing what they come up with. It was good to see knative on their roadmap! This could be something else majorly.

Re: Shifting Gears

#104

Post by sytse »

dominotw wrote: post #79
sytse wrote: post #30

Earlier quoted context omitted.

I agree this weakness comes from plugins. Because the plugins are not part of the main code base you can't introduce new functionality without breaking them. So you end up with a slow pace of development while you still end up breaking installations on upgrade. If you add functionality to the main codebase you can keep running your tests to ensure nothing breaks. This is what I think they will do with Cloud Native Je…

> Because the plugins are not part of the main code base you can't introduce new functionality without breaking them. This is a very simplistic explanation bordering on FUD. Jenkins defines something called 'Extension points' you can introduce new functionality as long as you don't break extension point contract you can continue to add functionality. For example, Greenballs plugin[1] is almost 11 yrs old and still wo…

I agree my explanation is simplistic but my intention wasn't to to spread FUD.

If you don't break the extension point contact plugins should break, but doing so is hard. Hence the breaking plugins.

The extension points also make it harder to improve Jenkins since they can't be changed without breaking plugins.

And when you introduce a new concept, like pipelines, with a plugin there isn't a well defined extension point for other plugins.

I'm aware of the Jenkinsfile functionality but I think this is different. If you follow the link "Jenkins Configuration as Code" in https://jenkins.io/blog/2018/08/31/shifting-gears/ it points to https://jenkins.io/projects/jcasc/ which has plugin management https://github.com/jenkinsci/configuration-as-code-plugin/bl...

I don't think you can do plugin management in a Jenkinsfile https://jenkins.io/doc/book/pipeline/jenkinsfile/ so it seems incomplete.

I've tried to explain it better with https://gitlab.com/gitlab-com/www-gitlab-com/commit/0639c998...

Re: Shifting Gears

#105

Post by dominotw »

sytse wrote: post #104
dominotw wrote: post #79

Earlier quoted context omitted.

> Because the plugins are not part of the main code base you can't introduce new functionality without breaking them. This is a very simplistic explanation bordering on FUD. Jenkins defines something called 'Extension points' you can introduce new functionality as long as you don't break extension point contract you can continue to add functionality. For example, Greenballs plugin[1] is almost 11 yrs old and still wo…

I agree my explanation is simplistic but my intention wasn't to to spread FUD. If you don't break the extension point contact plugins should break, but doing so is hard. Hence the breaking plugins. The extension points also make it harder to improve Jenkins since they can't be changed without breaking plugins. And when you introduce a new concept, like pipelines, with a plugin there isn't a well defined extension poi…

> The extension points also make it harder to improve Jenkins since they can't be changed without breaking plugins.

Yes its a tradeoff, very similar to programming languages/libraries that people write code against. You cannot change the api (eg: syntax of the language) without breaking existing code. It doesn't mean a language cannot improve, java is has continued to evolve. Solution to this not have all java code in the world to be in one repo.

> I don't think you can do plugin management in a Jenkinsfile https://jenkins.io/doc/book/pipeline/jenkinsfile/ so it seems incomplete.

I am not quite sure what you man by 'plugin management' but you can use plugins in Jenkinsfile https://jenkins.io/doc/pipeline/steps/

I think you are referring two different concepts.

1. Managing Jenkins configuration eg: configuring global npm password, global nexus config, typically done by jenkins admin). This was traditionally done via UI and configuation as code is the effort to do it via code.

2. Managing your build configuration, done by devs setting up their builds on jenkins. In the past this was done in the UI in job configuration. Jenkinsfile /pipeline is solution for that. You can check that file into your code repo. This is equivalent to gitlab-ci.yml.

The model here is that the admin enables and configures the plugin with defaults and global level via configuration-as-code and users use that plugin in Jenkinsfile.

Very similar to gitlab releasing 'dependencies' feature on their build server so that users can use that feature in their gitlab-ci.yml.

> I don't think you can do plugin management in a Jenkinsfile

Why would a user want to do plugin managment on the server in their Jenkinsfile? It would be like gitlab ci users upgrading their gitlab CI version via gitlab-ci.yml.

Re: Shifting Gears

#106

Post by peterwwillis »

michaelneale wrote: post #93
chinhodado wrote: post #2

Jenkins's biggest strength is also its biggest weakness: plugins. Any development shop that has been using Jenkins for a while is using at least a bunch of plugins. Plugins are not stable, they break every now and then. They require constant update with new Jenkins versions. They get abandoned by their creators (hell, many plugins still don't support pipeline). It's a fundamental issue with how Jenkins is set up that…

Part of the ideas mentioned are to resolve this stability, and not depend on in process plugins (a new extensibility architecture that won't hurt stability). There are many things in plugins which should be core functionality (and will be).

That's just the thing. Why has there been so little adoption of commonly needed functionality as part of core, or at least as officially supported plugins?

Like, there's no official backup functionality? And why is version control not standard in 2018? This isn't something you just bolt on, or incorporate as a response to competing products.

I think they should abandon all hope of Jenkins being competitive. They should remain the weird old school universal tool it always was, and let it become relegated to legacy systems, like the Apache web server.

Jenkins was useful, but it's living in the past and trying to solve the wrong problems.

Re: Shifting Gears

#107

Post by AlphaSite »

jacques_chester wrote: post #70
chinhodado wrote: post #2

Jenkins's biggest strength is also its biggest weakness: plugins. Any development shop that has been using Jenkins for a while is using at least a bunch of plugins. Plugins are not stable, they break every now and then. They require constant update with new Jenkins versions. They get abandoned by their creators (hell, many plugins still don't support pipeline). It's a fundamental issue with how Jenkins is set up that…

The deeper issue with plugins is that they create global state across everything . Switching the execution engine to Kubernetes will help a lot with operational pain. But consider the comparison to Concourse, which also predates Kubernetes. What drove Concourse into being wasn't the lack of Kubernetes (being born during the Diego project, itself a container scheduler), it was the amount of time and pain and unsafety…

I've done a ton of work with concourse and it has a very large set of tradeoffs if makes as well.

For example, resources are really nice, but there are a ton of pain points to do with how intentionally crippled the yaml pipeline format is (and in general how much repetition there is, due to the lack of looping, etc). Also the way i've seen people write pipelines tends to end badly for all involved.

Also its just very very buggy, especially if you deploy sans bosh, since thats basically not tested.

Re: Shifting Gears

#108

Post by michaelneale »

peterwwillis wrote: post #106
michaelneale wrote: post #93

Earlier quoted context omitted.

Part of the ideas mentioned are to resolve this stability, and not depend on in process plugins (a new extensibility architecture that won't hurt stability). There are many things in plugins which should be core functionality (and will be).

That's just the thing. Why has there been so little adoption of commonly needed functionality as part of core, or at least as officially supported plugins? Like, there's no official backup functionality? And why is version control not standard in 2018? This isn't something you just bolt on, or incorporate as a response to competing products. I think they should abandon all hope of Jenkins being competitive. They shou…

>That's just the thing. Why has there been so little adoption of commonly needed functionality as part of core, or at least as officially supported plugins?

Oh there are core bundled plugins, official etc - they are just core functionality that happens to be implemented by plugins.

>And why is version control not standard in 2018?

that is and always has been - "git" support used to be not in by default, but that was a while ago (it is included now).

Re: Shifting Gears

#109

Post by sytse »

dominotw wrote: post #105
sytse wrote: post #104

Earlier quoted context omitted.

I agree my explanation is simplistic but my intention wasn't to to spread FUD. If you don't break the extension point contact plugins should break, but doing so is hard. Hence the breaking plugins. The extension points also make it harder to improve Jenkins since they can't be changed without breaking plugins. And when you introduce a new concept, like pipelines, with a plugin there isn't a well defined extension poi…

> The extension points also make it harder to improve Jenkins since they can't be changed without breaking plugins. Yes its a tradeoff, very similar to programming languages/libraries that people write code against. You cannot change the api (eg: syntax of the language) without breaking existing code. It doesn't mean a language cannot improve, java is has continued to evolve. Solution to this not have all java code i…

> Why would a user want to do plugin managment on the server in their Jenkinsfile? It would be like gitlab ci users upgrading their gitlab CI version via gitlab-ci.yml.

This means that when a developer need a new plugin they need to ask the administrator of the Jenkins server, frequently a central IT organization.

With GitLab all the functionality is always enabled, there are no plugins to install.

I disagree that installing plugins is the same as upgrading GitLab or Jenkins itself. Although of course GitLab gets new functionality every month.

Re: Shifting Gears

#110

Post by tbugrara »

jonthepirate wrote: post #58

I worked on Jenkins at Lyft and completely set it up for DoorDash. If anybody needs help with their Jenkins setup, hit me up I give free advice and have a few blog posts on the matter. If you happen to be using AWS, GitHub, and Slack, we at DoorDash have developed lots of goodies for streamlining things. We have secured our Jenkins behind our VPN, created load balanced Jenkins clusters, built a shared Groovy library…

Oh god, please!
Post reply on HN