Repository Providers

Repository Providers (or RepoProviders) are locations where repositories are stored (e.g., GitHub). BinderHub supports a number of providers out of the box, and can be extended to support new providers. For a complete listing of the provider classes, see repoproviders.

Supported repoproviders

Currently supported providers, their prefixes and specs are:

Provider provider_prefix spec notes
GitHub gh <user>/<repo>/<commit-sha-or-tag-or-branch> GitHub is a website for hosting and sharing git repositories.
GitLab gl <url-escaped-namespace>/<unresolved_ref> (e.g. group%2Fproject%2Frepo/master) GitLab offers hosted as well as self-hosted git repositories.
Gist gist <github-username>/<gist-id><commit-sha-or-tag> Gists are small collections of files stored on GitHub. They behave like lightweight repositories.
Zenodo zenodo <zenodo-DOI> Zenodo is a non-profit provider of scholarly artifacts (such as code repositories) run in partnership with CERN.
Figshare figshare <figshare-DOI> FigShare is company that offers hosting for scholarly artifacts (such as code repositories).
Dataverse dataverse <dataverse-DOI> Dataverse is open source research data repository software installed all over the world.
Git git <url-escaped-url>/<commit-sha> A generic repository provider for URLs that point directly to a git repository.

Adding a new repository provider

It is possible to add new repository providers to BinderHub, allowing a BinderHub deployment to fetch repositories from new locations on the web. Doing so involves defining your own RepoProvider sub-class and modifying a set of methods/attributes to interface with the online provider to which you are providing access. It also often involves building a new repo2docker content provider.

In order to extend the supported repository providers, follow these instructions. We’ll provide example links for each step to a recent BinderHub pull-request that implements the DataverseProvider class.

  1. Review the repoprovider module. This shows a number of example repository providers.
  2. Check whether repo2docker has a ContentProvider class that will work with your repository provider. If not, then you’ll need to create one first.
  3. Create a new class that sub-classes the RepoProvider class. Define your own methods for actions that are repository provider-specific. For example, here is the DataverseProvider class.
  4. Add this class to the list of default RepoProviders in BinderHub.
  5. Add the new provider prefix to the BinderHub UI and the index javascript and make the appropriate changes to the index page based on the URL specification for this repository provider.
  6. Add a test for your repoprovider to ensure that it properly resolves and fetches a repository URL.
  7. Document your new repository provider on the Repository Providers page as well as the repoproviders page.
BinderHub API Documentation Configuration and Source Code Reference