Hacker News Reader

Comment by kohsuke | Hacker News Reader

If I understand you correctly, you are talking about managing Jenkins configuration as code. For that, see

* configure jobs as code (https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin)

* system configuration as code (https://issues.jenkins-ci.org/browse/JENKINS-31094) and its current prototype (https://github.com/jenkinsci/system-config-dsl-plugin)

* bypassing setup wizard (https://issues.jenkins-ci.org/browse/JENKINS-34035)

There are also puppet modules, Chef cookbooks, and etc that a lot of people use. Some of those are maintained by people who are also in the Jenkins community, so I don't consider them "3rd party hacks" if you are referring to those.

View on HN

And this is one of the major shortfalls of the Jenkins mindset. Everything is a plugin and an afterthought from the main design of the system. Something as crucial as configuring the system should be a top design priority, not shoved into a plugin 5 years after the launch of the project.

So, great, there is a plugin to deal with configuration. How do I bootstrap my infrastructure? If it's a plugin, it sounds like I need to install that in an already running Jenkins setup, no? Currently, both this and the bypassing setup wizard seem like hacks to me.

Configuration of a critical piece of your infrastructure should never be a hack.

Jenkins is more than 10 years old :)

Regarding plugins, you can just plop them in the plugins folder an start Jenkins.

What Jenkins should do is re-write all essential plugins as core functionality. That is one of the primary pain points people have.

Totally, I just was considering the fork point from Hudson back about 5 years ago. As an independent project they've had 5 years to think about design and it seems like no one really has cared.

I still think core functionality shouldn't be put into plugins in any software system. You should have sane functionality and defaults right out of the gate. Plugins or modifications are for extending the base use case. Configuring your software to me is a base use case.

Jenkins is incredibly popular and has a huge community. Dropping backwards compatibility would be very harmful.

What they did instead was to move most of the core functionality in plugins maintained by the core contributors, so they're plugins all but in name. I.e. they can be installed separately, uninstalled, etc., but about 100 plugins are supposed to be used together and you see them frequently in examples, docs, etc.

Plenty of systems can and do evolve their community forward with it. The sentiment of backwards compatibility at all costs is the same that leads you down the road of having to support IE 7. No one is saying play fast and loose with core functionality, but do it responsibly and with community input.

That "about 100 plugins are supposed to be used together" is indicative of bad design to me.

They really should be taking a look at modern systems like Concourse CI to see what they can do to improve.

Reply on news.ycombinator.com