repo filter for use with GitHub classroom
One good instructional use case for binder is combining it with GitHub classroom, which produces 100% predictable repo url names of https://github.com/org/baserepo-username. Is it currently possible to configure one's own binderhub to only accept url's that match https://github.com/org/baserepo-?
Currently not possible, but should be an easy addition to the GitHub repoprovider!
That would be great! Binderhub is still a snazzy solution for departmental clusters especially in conjunction with GitHub classroom, but we will want some safeguard for ensuring (hoping) that the cluster is being used for instructional purposes only. Snazzier than a z2jh because the department can leave the image definition to individual faculty to curate on their own.
@brooksambrose do you want to try take a shot at making a PR? :D
It’s Greek to me, but sure!
Hi, not sure if this is still open? If I understand what you want correctly, then one way would be to implement a custom repo provider that supports only your github classroom urls, and then you'd be able to configure your instance of binderhub to use only those providers. Would that work for you?
I think now you could implement this by writing an "inverse" regex for the "ban repositories" setting we have.
To expand a bit: BinderHub can be configured to have a list of regular expressions that specify which repositories should be banned. I think you could write a regex that matches everything except for the repo from your github classroom. It probably makes sense to also add a "whitelist" option to our config to make this use case a bit easier.
I've sent a proposal PR. If this gets merged, where should I document it? Is there a document that describes "how do I ban a repository" or "useful things to put into values.yaml"? I've only found the documentation of the methods repoproviders.py and some general information about values.yaml.
I think I'd add it under https://binderhub.readthedocs.io/en/latest/customization/index.html
The docs are pretty sparse/not super structured. We started with a "How to setup a BinderHub" guide and somehow the docs reflect that "walk through" style. A fresh pair of eyes and ideas would be welcome. In other/similar projects (like The Littlest JupyterHub) things were heavily inspired by https://docs.djangoproject.com/en/dev/internals/contributing/writing-documentation/#how-the-documentation-is-organized and I think people liked that. So maybe that is something to aim for/work towards.
Is #1105 something that still might be merged? Although one can use regexes with banned_specs, I think an allowed_specs is a cleaner configuration option that would definitely be useful!