I’ve found working with plugins to be a little tedious. Stumbling through correctly writing the pipeline commands and having to write many pipeline commands accomplish what to me is sometimes be a relatively cohesive task.
What are peoples experiences with just using a single ‘builder’ image with all necessary cli tools installed?
I’m starting to think this would greatly simplify my .drone.yml’s. It would also let me just use tools I already understand instead of having to learn how to pass arguments to many unique plugins correctly. I think i’m going to just go for it, but wondering if the community has encountered downsides I haven’t considered?
My 2 cents below. Keep in mind that this is generic advice based on assumptions since this thread does not have any real-world examples for us to analyze (which is ok, but means my response may not address your exact needs)
Opinion: Plugins or Builder images?
Plugins and build images serve different needs. More below …
I’ve found working with plugins to be a little tedious. Stumbling through correctly writing the pipeline commands and having to write many pipeline commands accomplish what to me is sometimes be a relatively cohesive task.
The purpose of plugins is to create re-usable components that you can share across projects. Not everything is re-usable, and in some cases, writing a plugin is more complex than writing the shell command or invoking a shell script. If you are creating plugins that are not re-usable across projects, plugins are probably the wrong tool for the job.
What are peoples experiences with just using a single ‘builder’ image with all necessary cli tools installed?
This is a common pattern. Teams create a base Docker image with their toolchain installed, and then use that image in the pipeline. This is especially helpful when teams have to apt-get install a large number of dependencies and they want to reduce their build times.
However, the idea of using a “single image” in your pipeline seems to be at the other extreme of using plugins for everything. Typically I would expect a pipeline to consist of both. For example, you might have a build image that you use to compile and test your code, and then you use a plugin to deploy and a plugin send notifications …
I really appreciate your input. I think the valuable take-away for me is that builder images, plugins and shell scripts are all reasonable and non-exclusive tools I can use in my build and deploy solution.
I may have forgotten to think outside the ‘box’, and was expecting a platform specific tool should be available that is tailored to my use case. I was worried opting for builder images and custom scripts was unconventional, but realize now its common and acceptable.
Thanks again, loving drone!
My opinion on CI plugins is that people all too often ask for integration to a certain platform, or hunting for plugins that do exactly what they need. Yes I’m taking about Jenkins, and then they try to keep the monstrosity together.
Forgetting that a plugin is just code they can encapsulate in a bash script and run it on a builder image. Just like you explained. If you can capture your task in a bash script, you can run it on a CI server.
So my goto tools are build images with all the tooling installed, and once a pattern emerges, I may extract it as a plugin.
What I like about Drone is that a plugin can be as simple as a builder image wrapping a shell script, setting that script as the container entrypoint, and documenting the common parameters of the plugin. Can’t be simpler than this.
