> > On Nov 18, 2015, at 17:32, domi <[email protected]> wrote: > > To be honest, the whole list of jenkins docker plugins feels like a zoo and > there is no way a normal user can keep up and make the right choice. Technically it’s a question to plugin manager and providing ratings & statistics. That afair will be enhanced soon. > I think this work should be coordinated better and an uptodate comparison > should be kept at a central place. > ..my 2cents @Domi, i thought the same and even tried to go through processes, but they are ends into project organisation (or miss organisation). What should i do if plugin author don’t want to use PRs or static analysing tools? Right, leave into fork.
What should you do if, for example, you make business around docker and jenkins and enough power to support yourself this code? You will of course make your own company internally decided plugins hierarchy. And project organisation of course allows you to make your development under jenkinsci hosting. That what i understand too late after personal talk with Kohsuke - his project is “bazaar”. You solve your cases and share sources and it’s usage. If you disagree you can do your plugin :). > /Domi > > >> On 18 Nov 2015, at 15:26, Kanstantsin Shautsou <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Tuesday, November 17, 2015 at 7:28:00 PM UTC+3, Jesse Glick wrote: >> On Mon, Nov 16, 2015 at 10:02 PM, kmbulebu <[email protected] <>> wrote: >> > I believe the real horse race is between the >> > underlying docker libraries. In the end, we'll likely have a clear winner, >> > and can standardize a group of plugins around that. Perhaps docker-commons >> > becomes that focal point, and we have smaller plugins that deliver slaves, >> > build steps, workflow DSL, etc. >> >> Seems reasonable to me to have smaller plugins with focused features, >> and a little competition. I would not object to hosting as is, >> provided that plugin wikis clearly link to alternatives. >> >> IIUC the main differences between your plugin and the `Cloud` portion >> of the `docker` plugin are >> >> · Different client libraries. No clear winner yet. >> I created small thread between docker-java and docker-client to unify >> efforts, but obviously it will be long time action and probably will have no >> results. Both libraries missing different things, but technically >> docker-client doesn't support callbacks for long running commands. >> >> · Slave launcher: yours uses JNLP; `docker` plugin currently ships >> SSH, has JNLP support in code but disabled. >> It was disabled because of lack of integration tests, ssh launching >> stabilisation was very hard and i didn't want to have broken instances with >> one more untested launcher. Those PR that tried enable JNLP was not exactly >> how it was planned to work from design view point. >> >> If you can later reach consensus with the `docker` plugin devs on the >> approach to take for a general-purpose Docker cloud provider, it >> should be possible to unify code into a new plugin release. Automatic >> migration of user settings will be a bit trickier but is possible. >> As soon as @magnayn likes "master development" without test cases he will of >> course merge any changes. So you are free to submit any PRs to docker-plugin >> now. >> >> By the way your comparison chart neglected to mention >> >> https://github.com/ndeloof/docker-slaves-plugin >> <https://github.com/ndeloof/docker-slaves-plugin> >> >> which is a novel approach that I think is very promising. >> Very promising thing will be finally implement normal Cloud API in core (or >> in plugin but provide normal extension points) because docker is not only >> the single cloud provider. >> >> PS i'm co-maintainer of docker-java atm and working on one more docker cloud >> plugin for jenkins which from my viewpoint will have the best implementation >> of currently possible state. >> TLS support in docker-plugin is also possible (or even already works) >> because docker-java resolves system variables for connection builder (though >> there is no right implementation for this field). >> PPS From tech viewpoint i see that "ephemeral cloud" has queue lock issues >> and shading. But if this plugin solves user issue, then it should be hosted >> and allow people experiment on it. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/d10a18f3-1c8c-4398-aecb-b9e474818ff4%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/d10a18f3-1c8c-4398-aecb-b9e474818ff4%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/S06tNF53NxA/unsubscribe > <https://groups.google.com/d/topic/jenkinsci-dev/S06tNF53NxA/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/127A6A84-F1F2-42C6-9195-922972EA3D68%40fortysix.ch > > <https://groups.google.com/d/msgid/jenkinsci-dev/127A6A84-F1F2-42C6-9195-922972EA3D68%40fortysix.ch?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/68729843-7006-4E2C-AC09-67F4F5677DC3%40gmail.com. For more options, visit https://groups.google.com/d/optout.
