In particular, I am writing a plugin providing tasks for running ‘buildah’.
In general, I am wondering if it is possible to include executables (like buildah) in the plugin and if so what is the recommended pattern for doing so?
‘buildah’ is written in GoLang.
I have read Custom plugin - extending Exec class and am wondering if there is an update.
I presume the recommendation is to ‘exec’ Project - Gradle DSL Version 7.3.1
…with the executable installed outside of the gradle plugin.
For standalone binaries, the usual pattern is that the plugin allows specifying a version that can then be downloaded from a distribution URL as needed. Baking the actual bits into your plugin JAR and writing them out somewhere would be discouraged.
However, given that this is not a standalone binary and really ought to be handled by the system package manager, it seems like trying to have the plugin provide a buildah binary would actually be a disservice to plugin users and likely to cause more headaches than help.
This solution is still valid and an acceptable way of handling it (calling project.exec in your own custom task action), but the issue of passing arguments to an Exec task could now also be handled with lazily evaluated CommandLineArgumentProviders.
External binaries such as ‘javac’ are made available via toolchains.
Might it be possible to write custom toolchains as part of a custom plugin?
You could certainly write something called a “toolchain” for your case, but you’d be starting from almost scratch. The Java toolchain was written specifically for Java, not built on a generic toolchain concept that you could implement slightly differently for another tool.
Yes, but they either use something that is already installed or they install a version from a stand-alone distribution (everything needed can be extracted to a folder from a single archive). I haven’t seen a buildah build distributed this way, but that’s close to a requirement barring any extreme low level work on your part.