When you’re working in an environment where you’re managing custom plugins that need to work on multiple agent platforms, it can be annoying/difficult to manage hooks. You have to worry about the nuances of how Bash works on the various platforms, or you’re managing duplicate functionality across Bash and Batch files. Also, Bash is a great scripting language, but more and more plugins are used for more complex purposes. Thus, I am proposing first class support for golang hooks.
Now, I 100% acknowledge that I can do what I want today by simply writing a Bash script to call my golang binary, but I’m proposing a more native solution where the existing structure of a plugin is replaced with a single go binary.
- All the hooks in a single build. The exact structure of this can vary, but I can imagine numerous ways to incorporate all the hooks into a single place.
- Automatic detection that determines which build of the hook we should call. If we establish that you need to build your binaries in a certain way, name them following a certain convention, and put them in a certain place, the buildkite agent could automatically call the correct build based on your platform.
- A golang library that makes it easy to write these hooks. Similar to how something like cobra is used to write CLI utilities, we could manage a library around hooks.
Now, if there is interest in this, I’m willing to offer my (company’s) services to help build/test this out. We are thinking of shifting towards “buildkite plugin driven development” where a lot of our automation is done inside Buildkite pipelines, and the “how” for that automation is stored in plugins.
What I’m looking for in terms of a POC is some feature flagged support for this functionality in the native buildkite-agent and ancillary services. What exactly this entails I think can be up for discussion based on the feedback this topic gets.
So, to those reading, if you think it’d be useful to be able to write Buildkite Plugins as Go binaries, please vote!