Support for special .github repository

[bkeepers]

One of the ideas a few people have been kicking around in the @probot community and within GitHub is the idea of treating a repository named .github as a special org-wide configuration repository.

probot/stale#106 switches the stale app to using this extension to start experimenting with this idea, and I created https://github.com/probot/.github to store the configs.

I also wanted to propose some changes to this extension that would treat .github uniquely:

1. If a user does _extends: .github, then read the file out of the root of that repository instead of a .github directory within that repository. For example, right now I had to put the configs in https://github.com/probot/.github/tree/master/.github to make it work.

2. Maybe even consider also looking in .github automatically. This will double the number of API requests for looking up config files, but would make make the .github repository a convention across probot apps.

Thoughts?

cc @JasonEtco @hiimbex

[hiimbex]

👍 I think this would be a great option for larger orgs, where the .github folder in every repo takes up space. It creates a nice repo for discussing org level administrative issues and the like. I think it is a powerful precedent to set, but obviously with the existing support.

[itaditya]

I also love this idea

[cco3]

I'm a fan of these ideas. In addition to the benefit for larger orgs, there are also projects that largely act as mirrors, where it is undesirable to change the upstream repo just to configure an app the runs on the mirror.

For 2, is the idea that all configs would, by default, extend org/.github? (That would make sense to me)

[dessant]

How will single file permissions work when a config file extends from the .github repo? Wouldn't it fail when accessing the config from the repo root?

[dessant]

For example, the stale app requests read-only access for the .github/stale.yml file path. Let's suppose the app is installed for the .github and test repo.

Accessing the config in the test repo will work as expected, but the current implementation will look for the stale.yml file path in the .github repo, when the config is not present in the test repo, or when we explicitly set the .github repo for the _extends config option. The config path that we extend from could also be set to anything else by users.

probot-config/README.md

Lines 44 to 74 in def82e6

	Additionally, you can specify a specific path for the configuration by
	appending a colon after the project.
	```yaml
	_extends: probot-settings:.github/other_test.yaml
	other: FFF
	```
	Note that by default, inherited configurations are in the **exact same
	location** within the repositories. However, if a base repository is named
	`.github`, the default config path is relative to the root of the repository
	rather than relative to a `.github/` directory.
	```yaml
	# octocat/repo1:.github/test.yaml
	_extends: .github
	other: GGG
	# octocat/.github:test.yaml
	other: HHH
	```
	Additionally, if there is no config file, but there is a repo in the org named
	`.github`, it will be used as a base repository.
	```yaml
	# octocat/repo1:.github/test.yaml <-- missing!
	# octocat/.github:test.yaml
	other: III
	```

It looks like you can access the config files regardless of the single file permission if the repository is public, so the single file permission likely comes into play for private repos, though I'm not able to test that part 😋.

It seems we would need to request read-only access to repository contents just to read the config files, or we would need to require that the .github repo (and any other repo where a custom _extends path is pointed to) be public.

This is easy to control in internal/self-deployed apps, but can lead to confusion during the use of a hosted app that works with probot-config.

Config file access could be explained in the README, so any app using probot-config can link to it from their own config/docs.

[gr2m]

I think this issue can be closed, but I would suggest to create a follow up issue regarding @dessant comment

How will single file permissions work when a config file extends from the .github repo? Wouldn't it fail when accessing the config from the repo root?

My assumption is that if the .github repo is private and the app has only single file access like .github/my-app.yml then it will fail

[z-hirschtritt]

Are we planning on cutting a release for this change?

[nesl247]

I think it makes more sense to make even the .github repo require .github/ instead of at the root level. It solves this for both public and private repos, and reduces the API load. Maybe deprecate the old behavior and do it as a fallback.

Basically revert #6 (which seems to have not thought about private repos) and add in a fallback for anyone depending on #6 functionality temporarily.

[bkeepers]

0.2.0 has been released with this feature. Huge 👏 to @cco3 for working on this, and @hiimbex for giving feedback and review.

[nesl247]

@bkeepers Should we open another issue then given that this does not work well for private repos?

[dessant]

@nesl247, yes, though we could just document the limitation instead of reverting.

[nesl247]

I've opened #13 to discuss it.