The Docker landscape in Jenkins is kind of a mess, but I do feel this is a good thing for an extensible open source project. The situation is exaggerated here because there is so much interest and momentum in Docker. We've discussed two Docker client libraries in this thread. There is a third, used by Jenkins/Cloudbees, that relies on calling the docker client from the command line. I know they're using it in the Docker Custom Build Environments plugin, but I believe it's used in all of the new Docker plugins that were released this year.
The approach calls the docker command line client and I think it is flawed approach. I would much rather see the docker-commons plugin become a focal point for a pure Java docker client, credentials management, and reusable jelly components. I believe this has worked out well for launchers and other 'common' plugins. Here's some of the issues I've encountered while working with the plugins that rely on the docker cli: 1. Requires an existing executor, on master or a slave, for use in invoking the docker client. A pure docker build environment isn't possible. 2. Docker clients are currently married by version to the server. Connecting to a 1.7.1 server, requires a 1.7.1 client. This breaks down quickly from a maintenance perspective. 3. The REST apis are built with API stability and backwards compatibility in mind, where as the cli makes no such guarantees. If we want to address divergent strategies, I think we should start with the above. -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c77af750-7924-4a02-a6e6-07e2fb3343d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
