Provide a way to utilize the `HTTPServer` instance used by probot about probot HOT 5 CLOSED

@MarshallOfSound take a look at #183 -- I think it fits your use case for exposing /panel in your original issue 👀

from probot.

Hey @MarshallOfSound, I'm 👍 for exposing the http server. You're welcome to take a crack at a PR for it, or I'll see if I can get to this soon.

Not sure if this is in scope for ProBot but my overall goal is to provide another module probot-swarm which allows you to run multiple plugins in one instance and each plugin can expose settings which will be controlled by the web panel. So things like response messages can be configured easily without rebuilding the plugin source.

FWIW, you can already deploy multiple plugins to one instance: https://github.com/probot/probot/blob/master/docs/deployment.md#combining-plugins.

I definitely want a way to unify settings for plugins, but was going to wait to see a few shake out and see what the common patterns are. In general, I have a strong preference that plugins store configuration in the GitHub repository, similar to how the stale, autoresponder, owners, and configurer plugins do.

I'd be curious if there are settings that you don't think belong in the repository themselves.

from probot.

@bkeepers Yeah, I guess I jumped to my solution instead of addressing the problem I want to solve 😆

Same kind of things, trying to make a standard for plugin configuration. The only reason I don't want the settings in files in the repository is I don't really like a lot of .md or . files cluttering up the entrypoint to a repo. It just makes things harder to navigate.

Maybe if we introduced an API to probot that made plugin settings standardized to be files inside a .probot folder or something (so we only have one top level entry)?

from probot.

The only reason I don't want the settings in files in the repository is I don't really like a lot of .md or . files cluttering up the entrypoint to a repo. It just makes things harder to navigate.

Yeah, I hear you there.

Maybe if we introduced an API to probot that made plugin settings standardized to be files inside a .probot folder or something (so we only have one top level entry)?

I've been using the .github folder for this, since GitHub already uses that for issue templates, and these are GitHub-specific integrations. Do you have anything against using that?

from probot.

I've been using the .github folder for this, since GitHub already uses that for issue templates, and these are GitHub-specific integrations. Do you have anything against using that?

It kind of makes sense as probot is purely a github integration thing, though in some cases the logical connection might not make sense.

For instance a probot plugin that sends slack notifications for certain types of PR, .github as a folder makes limited sense whereas .probot makes perfect sense. .github semantically makes sense depending on feature usage of probot, might make sense to allow .probot as well and let users choose how they do things 👍

What kind of structure are you thinking for these plugin setting files? Straight markdown, YAML / JSON files? Trying to imagine what sort of API we could expect 👍

from probot.