Whitelist labels

[Leland]

It'd be great to have the ability to run this bot only against certain labels – to whitelist labels, rather than blacklist all labels but those few we want.

[bkeepers]

@Leland that sounds like a good idea. What do you think about adding onlyLabels, and if it's set, it will only search issues with those labels? Otherwise, it will search all issues.

onlyLabels:
- question
- feature-request

One issue is that GitHub search won't properly handle ORing labels. It's not a deal breaker, but will probably just require a little refactoring and multiple API calls to get all of the issues.

[Leland]

@bkeepers love it.

[stkent]

@Leland @bkeepers I'm curious if either of you are working on this (couldn't tell from the discussion)? If not, I may give it a shot, but be warned I'm not a JS dev :P

[bkeepers]

@stkent I'm not, but would be happy to help you with it!

[stkent]

Awesome! Assuming @Leland isn't either, I'll start tomorrow and put up a PR that includes progress and questions at the end of the day :)

[Leland]

@stkent go for it!

[stkent]

First implementation question: what should the new defaults look like? We already have:

exemptLabels: ['pinned', 'security']

so I'm imagining something like

onlyLabels: []
exemptLabels: ['pinned', 'security']

for backwards compatibility. Then we run into the following question: do we allow folks to specify both non-empty onlyLabels and non-empty exemptLabels in the same configuration?

• If no, users who wish to use non-empty onlyLabels will also have to specify exemptLabels: [] explicitly in their config files;
• If yes, we'll have to decide if onlyLabels trumps exemptLabels, or if we combine the two somehow (by defining the behavior for a label appearing in both).

The path of least resistance would seem to be having onlyLabels trump exemptLabels whenever it is non-empty. Thoughts?

[boneskull]

Mocha could use this behavior. @stkent I will happily pick this PR up if you don't want to follow through for whatever reason.

Insofar as "operator precedence", cron will ignore "deny" if "allow" is specified. This seems reasonable to me (since there's a precedent, though it's not necessarily the source of truth!).

[stkent]

@boneskull excellent information, thanks! Given your 👍 and that precedent, I think proceeding down the path I outlined is indeed reasonable.

I'm going to be traveling through the weekend and will be unable to work on an implementation before Monday, so by all means pick up and run with this if you have the bandwidth! (If you do, please post back to confirm to head off any double-dipping.) I went through the project/plugin development setup process already and fixed rough patches that slowed me down in PRs, so you should be able to get up and running pretty quickly if you so choose!

[stkent]

Picking this up again today!

[stale]

Is this still relevant? If so, please comment with any updates or addition details.

[humitos]

Haha! The stale probot will close his own issues :)

It's still relevant to us at Read the Docs, we are waiting for this feature to be implemented some day so we can start using this amazing bot.

Hopefully, some caritative soul will do it :D

[stale]

Is this still relevant? If so, please comment with any updates or addition details.