Plugin param explanation

I’m on drone 0.8.4.
Posting here as it’s a general question as to how the params are passed into plugins. I’m brand new to go, and might write a drone plugin, but found something that I can’t seem to link up to the code.

allowed.branch.regex, I can see is brought into the plugins variable BranchRegex

What I don’t understand (unless there’s a plugin bug) is how do I track the allowed.branch.regex into the code. Presumably drone will parse the yaml file, and the git repo being used, and pass that in as a CLI parameter. However, in my yaml config I can’t seem to get a valid branch filter.

This plugin seems to use an old version of the Plugin API, as it doesn’t contain the Config section, so maybe it’s just not compatible with 0.8?

I’ve tried a few config variations including the first one I thought would work:

      branch: [ master, feature/* ]

No luck… can someone help my understanding here?

Plugin variables are passed as environment variables and each property is prepended with PLUGIN_ so that’s why you see in the plugin code PLUGIN_ but you don´t have to write it like that in your spec.


    language: somelanguage
    allowed_branch_regex: feature/* # custom plugin logic
    profile: aprofile
    when: # Drone logic for pipeline conditions
      branch: [master, feature/*] 


Most of the plugins I’ve looked at use dashes in these names, so the dots threw me thinking there was a need in the config to have the hierarchy match the dot syntax. Or if that syntax was leveraging the existing drone models.

The dots are related to the name of the variable inside the plugin but if you see.

EnvVar is the source so there is the confusion

@brettswift I recommend reading this tutorial for writing a plugin in bash

thanks for the clarification. that tutorial makes more sense now.

Also you mentioned being new to Go … note that plugins are language agnostic. A plugin is just some program / script bundled in a Docker container that reads environment variables as input, writes output to stdout/stderr, and uses the exit code to signal whether or not execution was successful.

Here are some examples of plugins written in various languages:

Hope that helps!

Definitely does… I know plugins are language agnostic, but wasn’t sure I was following the drone code.

For posterity, I’ll put this link in here as well… but ask if this is still valid.

I think I read somewhere that the site is deprecated or out of date.

Thanks Brad!

For posterity, I’ll put this link in here as well… but ask if this is still valid.

Yes, that document is still valid