feat: configure excluded repositories and commands

[lemeurherve]

Ref: #54

I'm proposing to define excluded repositories with an env var containing the list of excluded repositories separated by a comma.

(PR in draft, need to add the corresponding value to the chart)

To exclude a repo, an help desk issue could be opened to add the repo name to this env var.

WDYT @timja @dduportal @daniel-beck

[timja]

I think this needs to be a bit more powerful, i.e. I don't think anyone would object to reviewers being requested.

It should have multiple levels,

e.g.

• repo
• repo:command
• repo:command1,command2

Along with tests and the code itself shouldn't be in the router it should be in it's own file which can be tested more easily

[jetersen]

Another option, could be to use https://github.com/probot/octokit-plugin-config as it provides config at a repository level. Potentially also at org level via .github repo.

This only provides a config at deployment of application.
As I understand this github-comment-ops is deployed for all to use on GitHub, so the last option is not really at repository level. 🤔

[timja]

Looks interesting does that mean it loads single files from github? I get that doesn't use API limits.

Not currently using probot here FWIW.

[jetersen]

Yes it can load a single yml config file and parse it to a object with sensible defaults. See release-drafter for usage: https://github.com/release-drafter/release-drafter/blob/master/lib/config.js

This is only partly related to probot. This is an octokit plugin. So since your using octokit, you can use it.

[lemeurherve]

That's why I went with an env var, easy to configure at the org/app level, to avoid fetching a file every time.

It should have multiple levels,

e.g.

repo
repo:command
repo:command1,command2

Totally, will fixes my other fr.

[jetersen]

@lemeurherve problem I can add jenkinsci deployment of github-comment-ops to any github org.
If other uses wanted to start using it they do not have the same option of adding something to your environment deployment.

[lemeurherve]

If other uses wanted to start using it

I might miss something but if people want to use this app in their org they can deploy the chart to setup their instance as they please?

[jetersen]

True. But also I can use your existing application as you have installed it for all of GitHub to use. So basically why would anyone deploy their own version if they can use the Jenkins hosted one?

[lemeurherve]

To be able to configure their own exclusions? 🤷

[jetersen]

With environment variables they cannot. With a config file in a repository they could.
Potentially they could also on an org level completely block transfer command.

[timja]

I think a config file would give us the flexibility we need, org level defaults and then allow repository overrides,

something like:

config:
  commands:
    - name: transfer
      permission: member
      enabled: true
    - name: labels
      permission: member
      allowed_labels: ['enhancement', 'chore', 'bug']
      enabled: true
    - name: close
      enabled: false
    - name: reopen
      enabled: false

[jetersen]

Yup this would work because configs are deep merged :)

An array would be perfectly merged with defaults in the org.

[timja]

Another option, could be to use probot/octokit-plugin-config as it provides config at a repository level. Potentially also at org level via .github repo.

This only provides a config at deployment of application. As I understand this github-comment-ops is deployed for all to use on GitHub, so the last option is not really at repository level. 🤔

I've started this approach here:
#60

[lemeurherve]

Closing in favor of #60