Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve remote git references using provider agnostic method #843

Closed
manics opened this issue May 7, 2019 · 2 comments
Closed

Resolve remote git references using provider agnostic method #843

manics opened this issue May 7, 2019 · 2 comments

Comments

@manics
Copy link
Member

manics commented May 7, 2019

Follow up from https://discourse.jupyter.org/t/how-to-use-bitbucket-repositories-on-mybinder-org/1000/4

Proposed change

  • Resolve branch names using git ls-remote in the bare git provider
    class GitRepoProvider(RepoProvider):
    """Bare bones git repo provider.
    Users must provide a spec of the following form.
    <url-escaped-namespace>/<resolved_ref>
    eg:
    https%3A%2F%2Fgithub.com%2Fjupyterhub%2Fzero-to-jupyterhub-k8s/f7f3ff6d1bf708bdc12e5f10e18b2a90a4795603
    This provider is typically used if you are deploying binderhub yourself and you require access to repositories that
    are not in one of the supported providers.
    """
    name = Unicode("Git")
    def __init__(self, *args, **kwargs):
    super().__init__(*args, **kwargs)
    url, resolved_ref = self.spec.rsplit('/', 1)
    self.repo = urllib.parse.unquote(url)
    if not resolved_ref:
    raise ValueError("`resolved_ref` must be specified as a query parameter for the basic git provider")
    self.sha1_validate(resolved_ref)
    self.resolved_ref = resolved_ref
    self.unresolved_ref = resolved_ref
    @gen.coroutine
    def get_resolved_ref(self):
    return self.resolved_ref
    def get_repo_url(self):
    return self.repo
    def get_build_slug(self):
    return self.repo
  • Potentially also replace provider specific API calls to resolve branch names

E.g.:

git ls-remote https://bitbucket.org/ueacomputervision/image-labelling-tool
f3ddb33e4839f8a0fe73c168993b405adc13daf0        HEAD
8116559e4030d1d4f557617780410cbca7896663        refs/heads/canvas
d50105bacbb74ca139c5bf38ef1657190a006929        refs/heads/group
f3ddb33e4839f8a0fe73c168993b405adc13daf0        refs/heads/master
0b92e511ce8e04f26131efddde9b4a2f5ef9e1e1        refs/heads/multi-user
bc53e6aa12b6d7988de514c8c92e29877be5cc61        refs/heads/separate-modules
a1b2c3bcc2e563afbd335013805d19c95d67224d        refs/heads/server-side-refactor
$ git ls-remote https://bitbucket.org/ueacomputervision/image-labelling-tool master
f3ddb33e4839f8a0fe73c168993b405adc13daf0        refs/heads/master

As indicated in the linked discussion currently the resolution of branch-names to sha1s is done using provider specific API calls, for anything unsupported users must figure out the commit hash themselves.

Who would use this feature?

Anyone not using GitHub or GitLab.

@betatim
Copy link
Member

betatim commented May 7, 2019

You think you know a lot about Git and then something like this comes along. Every day is a school day! We should definitely add this to the "bare git repo provider". For GitHub, Gitlab.com and others where we have an API we can call I'd leave things as is. It works, it is cheap and we have a good caching setup.

For bare git repositories this will be a major usability improvement!

@betatim
Copy link
Member

betatim commented Aug 8, 2019

Closed by #895

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants