bronto supports exec plugins, the same way git, kubectl, and gh do. Any executable
named bronto-<name> on your PATH becomes bronto <name>.
How dispatch works
- The plugin name must be the first argument.
bronto errors --helpruns the plugin with--help.bronto --profile prod errorsdoes not dispatch, because a flag comes first. Put global flags after the plugin name and let the plugin handle them. - Built-in commands always win. A
bronto-searchexecutable can’t replacebronto search. - Names are restricted to lowercase letters, digits, and dashes.
- If several directories on
PATHcontain the same plugin, the first one wins, as with any command lookup. - The plugin’s exit code becomes
bronto’s exit code, and its output passes through untouched.
bronto plugins list shows the plugins it finds on your PATH, as a NAME and PATH
table. With the script above installed, it lists errors and the script’s path:
Credentials for plugins
Plugins inherit your environment, but not the key stored in your keychain. A plugin that needs the Bronto API can get credentials in two ways:-
Call
brontoitself, as the example above does. The nested call resolves credentials the normal way. -
Ask for the key with
bronto auth token, which prints the key the CLI would use:
BRONTO_API_KEY before running the plugin.
For one-off API calls without writing a plugin, see the api command.
