Blue Ocean • Hacker News Board

Re: Blue Ocean

#181

Post by mtalantikite » Wed, Dec 21, 2016, 7:15 PM UTC

oblio wrote: post #169

mtalantikite wrote: post #128

Earlier quoted context omitted.

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 n…

Jenkins is more than 10 years old :) Regarding plugins, you can just plop them in the plugins folder an start Jenkins.

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.

Re: Blue Ocean

#182

Post by oblio » Wed, Dec 21, 2016, 8:46 PM UTC

mtalantikite wrote: post #181

oblio wrote: post #169

Earlier quoted context omitted.

Jenkins is more than 10 years old :) Regarding plugins, you can just plop them in the plugins folder an start Jenkins.

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. Config…

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.

Re: Blue Ocean

#183

Post by dmux » Thu, Dec 22, 2016, 2:20 PM UTC

vorg wrote: post #144

karlmdavis wrote: post #115

Earlier quoted context omitted.

FWIW, if you fight through the "undocumented features," Jenkins actually ends up being one of the best tools out there to manage via Ansible or whatnot. The Groovy/Java API for Jenkins is incredibly powerful, and by adding Groovy scripts to the /var/lib/jenkins/init.groovy.d/ directory, you can configure just about anything. Maybe this will be helpful? Here's the Ansible config I've built for a Jenkins deployment I m…

Apache Groovy also has "undocumented features", e.g. from your scripts: matchingSecret = secrets.find { secret -> secret.id == id } can be written as: matchingSecret = secrets.find { it.id == id } Those scripts look fairly basic, without any looping. Perhaps Java 8 with lambdas, or Kotlin could be used instead.

For more about this, see the documentation relating to the "implicit parameter"[0]

[0] http://groovy-lang.org/closures.html#implicit-it

Re: Blue Ocean

#184

Post by mtalantikite » Thu, Dec 22, 2016, 10:16 PM UTC

oblio wrote: post #182

mtalantikite wrote: post #181

Earlier quoted context omitted.

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. Config…

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,…

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.

Re: Blue Ocean

#185

Post by neuland » Sat, Dec 24, 2016, 10:11 PM UTC

sytse wrote: post #146

agibsonccc wrote: post #120

Esoteric use case from someone in AI: Jenkins is the only CI we've been able to use even as an open source project due to needing gpus. CI and things like special hardware is a "semi-common" edge case and a big reason to have something self hosted. Referencing other comments here: We've also found periodic builds and arbitrary jobs to be a must as well. A lot of providers out there support most of the basic stuff out…

In GitLab CI you can use any machine for a build as long a you can install GitLab Runner on it. We kept the design of that simple with few dependencies and it is written in Go.

So, you're saying that you can use tags [0] to specify that a runner has some special hardware like GPUs. Then in the project set a job to only run on a runner with those tags [1].

Is that right?

[0] https://docs.gitlab.com/ce/ci/runners/README.html#use-tags

[1] https://docs.gitlab.com/ce/ci/yaml/README.html#tags