Open dylanpyle opened 8 years ago
Great suggestion!
I feel a little nervous making assumptions about different teams' workflows (e.g., many teams may wish to split PRs among non-admin users, or a subset of repo contributors), but enabling explicit many-to-many configuration would be a big improvement.
Keeping with the current implementation, your suggestion of a per-repo ENV
param seems like the sensible step forward—no dependency on the filesystem, and the configuration stays in one place. It's easy to imagine this opening the door to reusable groups of users or collections of repo policies, but we might as well meet the many-to-many need without checking in configuration files or introducing a datastore.
Regarding implementation, though it sounds like you've already considered it: it should be a fairly small step to replace the current code's reliance on the (singleton, ENV-based) config with a lookup based on the corresponding evt.Repo
.
Another option: mention-bot (which, incidentally, looks like a subtler/more-sophisticated/github-specific version of the same) allows a checked-in dotfile to configure the repo settings, with the advantage of keeping configuration very close to the code.
Thoughts on the best way to accommodate a different set of assignees for different repos? Ideally I could have one instance of this app serving multiple repos, where there's a many-to-many relationship between reviewers and repositories.
Some initial ideas:
COOL_REPO_ASSIGNEES=rjz,alice,bob...
). Seems a bit messy.