Hey, I’ve been playing around with the new Drone Configuration Plugins and came up with something that I call drone-ignore. It’s like .gitignore or .dockerignore, but for Drone: you list some patterns and if a commit only includes files that match these patterns, the build is skipped.
Figured it could be useful to avoid triggering large deployments because someone fixed a typo in the README and forgot to add [ci skip] to the message, so decided to share here.
Anyway, what I’d really like to do instead is to be able to select which steps will run, depending on which files changed, as described here. I may try to tackle this problem soon so if anyone is already working on that and would like to team up please send a message
I’m really excited to configuration plugins being created!
This causes the build to be skipped, while also unfortunately logging an error on the Drone server.
I agree, I will try and figure out an option (perhaps a special error and special http response code) that signals to Drone that the pipeline should be skipped, instead of erroring. In the meantime, you could probably just return a dummy yaml that can never be executed, something like this:
Oh, nice idea @bradrydzewski ! I hadn’t thought about using the exclude keyword. I had thought about an empty step list but of course the “clone” step would still be executed. Exclude should fix that.
By the way, I had a couple of questions about configuration plugins.
Are there any restrictions on the license I should use? By default I use MIT but the starter example uses BSD, and jsonnet uses the custom Drone license.
Is there any way to combine multiple config plugins? For example if I wanted to use both jsonnet and ignore plugins. It seems that the current architecture does not allow that, but I assume it’s something you’ve thought about.
I think Drone supports this use case, but probably not in the way you want it to. You would have to combine the logic into a single plugin. You might be able to import code from the jsonnet plugin and the droneignore plugin directly (as opposed to copy/pasting).
The design goal for configuration plugins is to give teams a way to override how Drone fetches the yaml for the purpose of customization. The current design does not try to do anything more than this.
Might be worth mentioning this repo: GitHub - microadam/drone-config-plugin-pipeline, which attempts to address this. In our case, we’re currently adding features to a drone-yaml-plugin and updating by hand.
