New repos created on Github seem to be given the default branchname main rather than master (New GitHub Repositories Default to Main Branch).
Pasting the repo URL into MyBinder, the build shows a failed build with message: "Could not resolve ref for gh:ORG/REPO/master. Double check your URL."
Relates to: https://github.com/jupyterhub/binderhub/issues/1145
Hey @psychemedia! 馃憢 We were just discussing this in Gitter!
I can devote some time to addressing this next week
TODOs:
master to be main. PR https://github.com/jupyterhub/binderhub/pull/1172if unresolved_ref == 'master' or 'main' and expanding the message in those two cases (main == likely user used default and repo uses master; master == likely old link, repo has been updated to use main) PR https://github.com/jupyterhub/binderhub/pull/1170Would a really quick stop gap be to check for the Could not resolve ref for gh:ORG/REPO/master error message and add an additional hint: "Github has changed and in the meantime, we're working on it: for now, do you really mean the main branch?"
Would you like to make that PR? The relevant line is linked in my second TODO point.
@sgibson I could probably tweak the template addressing point 3, eg add something to tutorial block, but I'm not really set up test anything code wise. eg after <h4>New to Binder? Get started with a Zero-to
<h4>Seeing a <tt>Could not resolve ref / double check your URL</tt> error? New Github repos use <tt>main</tt> rather than <tt>master</tt> for the the default branch. Check whether you need to set the branch to <tt>main</tt>.</h4>
@psychemedia I'm co-working with someone who can help with that next week, I specifically meant your quick stop gap fix.
Not to worry, I can do this next week. I'm just in meetings all day today and working on the helm side of the federation tomorrow.
@sgibson re: the link to where the fix could take place, I think that is an incorrect link (link to helm chart discussion issue?)
Correct line here maybe?
Correct :) I've updated my original comment, thank you
So in my world, a hacky route would go from:
if ref is None:
await self.fail("Could not resolve ref for %s. Double check your URL." % key)
return
to:
if ref is None:
fail_message = ["Could not resolve ref for %s." % key]
unresolved_branch = key.split("/")[-1]
if unresolved_branch == "master":
fail_message.append( 'Github recently changed default branches from "master" to "main". Did you mean the "main" branch?')
elif unresolved_branch == "main":
fail_message.append('Github recently changed default branches from "master" to "main". Did you mean an original "master" branch?')
fail_message.append("Double check your URL.")
await self.fail(" ".join(fail_message))
return
but you probably want something cleaner than that...
But as I say, I'm not really in a position to test it...
Thank you for the code snippet @psychemedia. I opened PR #1170 but haven't quite managed local testing yet.
@renefritze I'm not sure. As far as I can tell, gists don't have a branch structure so... no? If an old gist launches fine, I'd guess it's some of our more normal, familiar bugs (馃槄). If you have an ad-blocker enabled, disable it and try launching again?
I tried this with firefox and no plugins. I've now tried to clone both gists to my local machine and both have a master branch checked out afterwards. Should I open another issue then for this?
Yes I think so, thank you. I'm not entirely sure if this is the same problem, but seems related somehow.