Configuration for probot has always been difficult. For context, originally, the goal of probot was to use only information from GitHub itself, with no outside data storage. However, this lack of data persistence has caused some problems and will continue to create issues down the line.

This proposal has 2 main parts: Individual Config Files for Repos along with their naming conventions and Organizational Level configurations.

🚂 JOIN ME ON THIS LONG ISSUE JOURNEY 🚂

Individual Config Files for Repos

The original probot apps each had individual configuration files usually closely tied to the name of the app that lived in .github/ folders. One example being stale, and its configuration settings lived in a .github/stale.yml file. During the great intern takeover of 2017, I decided this idea was silly. Each app having it's own individual file was not fun when you had 6 or 7 apps running on a single repo and each config file was only a few lines long.

So I created behaviorbot which uses a mutual/shared .github/config.yml for all of the apps within the org. People generally think this is a good idea, so I'd move to adopt future apps to have their settings as such:

# .github/config.yml file

stale:
  staleKey1: staleValue1
  # accessed by config.stale.staleKey1
  staleKey2: staleValue2
welcome:
  welcomeKey1: welcomeValue1
  # accessed by config.welcome.welcomeKey1
  welcomeKey2: welcomeValue2
# etc.

Obviously we don't want to break support for older apps, so we should also support:

# .github/stale.yml file

staleKey1: staleValue1
# accessed by config.stale.staleKey1
staleKey2: staleValue2

(and the kinda weird/slightly different way I named things in the behaviorbot .github/config.yml)

• It is important that we be able to access these both via config.stale.staleKey1 and have the API on probot's end check for the existence of either of these and use that to populate the config we are returned. (Note: config.staleKey1 is not as clean of a solution given stale could have one of the same key names as welcome, so we must for .github/stale.yml files place them into a stale object.)

• The only other relevant discussion here is the naming of the standardized configuration file. Currently the convention used is .github/config.yml; however, it is worth taking into consideration whether we want this file to be in a .github folder given this isn't a GitHub sponsored or owned project. It is also worth considering a name like probot-config.yml to add to our own branding and clarify that this is a probot specific configuration. 🤖
  My personal opinion is to keep using .github/config.yml given the existing apps that depend on it and it's already implemented/being accepted. And, honestly, none of the arguments for swapping naming conventions are particularly convincing to me. I'm open to other opinions though.

Organizational Level configurations

Right now doing any configuring at an organizational level sucks. Some folks have written scripts to do this, but adding a config file to every repo you want a bot to run on in an organization is really difficult, so we should aim to fix that! 🛠️

Potential Solutions/Ideas:

1. Add support for copying settings from a 'default' repository repository-settings/app#29 lays out a plan for a model using inheritance in which every repository has a config file, but it simply contains a line that says inherit: <repo name>, where the repo named in the configuration contains the actual config file settings that would be applied to the other repos.
   Pros:

   • Allows to easily opt in or out of specific repos within an org (ie you want only half of your repositories to use that app and that shared config or you want half your repos to use 1 configuration and the other half to use another)
   • Editing one configuration file effectively "updates" all files inheriting from it

   Cons:

   • You still have to add a configuration file to every repo you want the app to act on

2. Global configuration behaviorbot/welcome#9 and some out loud discussion during office hours discussed creating a repository upon app installation (for example your-org/probot-settings) that would always be used by the apps when searching for settings. The settings here would apply to all repositories in the organization.
   Pros:

   • Easily edit your config from one location that has org wide effect
   • Potentially have individual repos with their own config files that act as overrides for repos that need different settings
   • Helps probot branding by making our settings more visible? (only if this repo is public, not private)

   Cons:

   • We would need to come up with a way for disabling for an individual repository easily?
   • Some organizations might not like having a repository added just to hold our settings

3. 🚨 Data persistence 🚨 use some sort of simple key/value store to store data for the configuration which would be bound by some hashing or encrypting of the private key. This would be accessed through a simple web UI that we would redirect to upon an app's installation.
   Pros:

   • Easy to retrieve info for each repo on our end
   • Easy for the user to edit their settings at any time

   Cons:

   • We would prefer to avoid this kind of data persistence for security reasons and the pain of building out such a web UI. (In the past this seemed a lot more undoable, but as probot grows, I see the cons for this one shrinking)

tl;dr We need to standardize the way we do configs in order to provide better user experience. We can only do this once since many apps will start using these standards, it will become hard to undo/change.

Open to any further thoughts/ideas/opinions/implementations/troutslaps 🐟 about anything discussed here.