My org is interested in using multiple configuration extensions in some cases. Perhaps we want to use the jsonnet extension for defining our builds, but also want the features of the paths-changed plugin.
We can currently only run one extension so we must choose. Currently the best bet is to probably generate the .drone.yml from jsonnet and check it in. But we don’t really love that.
We could also write another plugin that defers to multiple downstream config extensions in sequence, but that is tricky with signatures and everything, and I’d rather not.
What if drone itself could handle multiple config extensions:
Could be simple comma separated list of urls, and an equal length list of secrets. The drone server would call everything in the list in sequence and let each one modify the config in turn.
This makes sense to me for config extensions, but maybe not for all others.
For an immediate solution, the jsonnet extension is a configuration extension and the paths changed extension [1] is a conversion extension. Since they are two separate extension types, you should be able to use both at the same time. But I certainly agree with your post that we need to support multiple configuration extensions at the same time.
This got a little complicated today. Here’s what I found:
The drone-jsonnet standalone extension really did not like my config that returned an array at the top level. drone jsonnet --stream and the built-in jsonnet mode work just fine though.
The built-in jsonnet works ok for me (even though it has no importer), but it is implemented in the conversion plugin list, and convert.Combiner short-circuits after the jsonnet evaluates, so the paths-changed extension never gets called.