You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support an alternate default repo to .github via environment variable or other setting.
Why?
Currently this plugin allows for a central / default config to exist in the organization's .github repository. This repository is public by design. This results in information leakage around any configuration options for repositories within the organization and makes auditors nervous (or makes them outright say we can't do this). Examples include teams with certain permissions, users, etc.
Alternatives you tried
None. I can't see a workaround to this other than having settings only in each private repo, which isn't DRY and puts a lot of overhead on the configuration of each repo instead of via a central bot/plugin like this system.
The text was updated successfully, but these errors were encountered:
derekmurawsky
changed the title
Alternate default repo
Alternate default repo (not .github)
Aug 31, 2022
The .github has been hard-coded since we introduced the feature in GitHub, I cannot recall anyone asking to make that default configurable. Do you use this library directly or through Probot?
I would not add environmental variable support, that should happen outside of this library.
It's an octokit plugin, so custom parameters would need to be passed to the Octokit constructore, e.g.
For the time being, I'd suggest you fork this plugin and publish your fork for your own usage. Given that nobody asked for this in the past, it's not something that I'd see us prioritize
What’s missing?
Support an alternate default repo to .github via environment variable or other setting.
Why?
Currently this plugin allows for a central / default config to exist in the organization's .github repository. This repository is public by design. This results in information leakage around any configuration options for repositories within the organization and makes auditors nervous (or makes them outright say we can't do this). Examples include teams with certain permissions, users, etc.
Alternatives you tried
None. I can't see a workaround to this other than having settings only in each private repo, which isn't DRY and puts a lot of overhead on the configuration of each repo instead of via a central bot/plugin like this system.
The text was updated successfully, but these errors were encountered: