gddo
gddo copied to clipboard
golang
non-master branches not being recognised
I am trying to generate the documentation for a custom domain: .works but I get a 404:
https://godoc.org/srcd.works/go-billy.v1
https://gotools.org/srcd.works/go-billy.v1 works okay, so this is indeed a gddo-specific issue.
My first guess was to check validTLDs, but ".works" is present there. In fact, gosrc.IsValidRemotePath("srcd.works/go-billy.v1") returns true:
$ goexec 'gosrc.IsValidRemotePath("srcd.works/go-billy.v1")'
(bool)(true)
So the issue must be elsewhere and will require further investigation. Spinning up a local instance of gddo, or looking in the log entries, is probably the fastest way to figure out what it is.
Edit: Here's some output from trying this on a local instance:
2016/12/21 19:00:52 git ls-remote --heads --tags https://srcd.works/go-billy.v1
2016/12/21 19:00:53 web fetch: 1860 notfound: Tag or branch not found. srcd.works/go-billy.v1
(This is assuming the latest master version is deployed to production, but I'm pretty sure gosrc package hasn't changed very recently.)
gddo uses default "master" tag for custom domain, while yours doesn't have a "master". Maybe we should change the behavior to match "go get"?
Maybe we should change the behavior to match "go get"?
I believe we should. I don't see a reason why godoc.org/<import path> shouldn't be able to display documentation for some <import path> that go get <import path> works on.
@shantuo master is a convention name, what we should get/clone is the commit pointed by the HEAD branch, some packages hosted in github may not have master as default branch and some other even the don't have a master branch. BTW nice catch
I can change go-stable to create a master branch pointing to the same commit pointed by HEAD, but those repositories with non-master branch at github will fail anyways.
Not sure if this is the best place to discuss this, but the behavior of non-master branches not being recognized is also present on go-talks.appspot.com. The getGithubPresentation function under https://github.com/golang/gddo/blob/master/gosrc/github.go#L197 hard-codes master into the url.
@smasher164 Given that it uses slightly different code (although also in ./gosrc package), it'd be best to open a separate issue to track that. You can refer to this issue, since it's related.
The introduction of Go modules is making this issue more critical: I've had to switch the default branch of the Goa repository (github.com/goadesign/goa) to match the branch that contains the latest major version of the Go module (v3). This is to make sure that users looking at the source code see the latest version while maintaining backwards compatibility for users of the pre-existing master branch (which isn't compatible with Go modules). I expected https://godoc.org/goa.design/goa/v3 to work but it doesn't because this Go module only exists in the v3 branch. The net result is that as of today users of Goa cannot see the documentation for the latest version on godoc... The only choice seems to tag the existing master branch, to clobber it with the v3 branch, and to inform all users to use the tag which obviously isn't great. Is my analysis correct? any chance that gddo may support non-master default branches? As mentioned in other comments go get works just fine.
@raphael For full module support, you should use pkg.go.dev. See https://github.com/golang/go/issues/33654#issuecomment-553496652 for more information about it.