-
Notifications
You must be signed in to change notification settings - Fork 503
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
Download: get /list from upstream #300
Conversation
Codecov Report
@@ Coverage Diff @@
## master #300 +/- ##
==========================================
+ Coverage 40.72% 40.75% +0.02%
==========================================
Files 97 97
Lines 2394 2395 +1
==========================================
+ Hits 975 976 +1
Misses 1316 1316
Partials 103 103
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments, overall I love this!
One thought I had was that we could further separate the proxy vs. registry endpoint logic & upstream "fetchers"
I have some of that in progress at #291, and we can discuss in follow-ups. This is a massive and awesome start
Makefile
Outdated
docker-compose -p athensdev up -d mysql | ||
docker-compose -p athensdev up -d postgres | ||
# docker-compose -p athensdev up -d mysql | ||
# docker-compose -p athensdev up -d postgres |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marwan-at-work why comment these out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arschles ops, didn't meant this to be in the PR. But now that it's here: we're not using mysql/postgres in development are we? I keep commenting this out because they take a while to build up and tear down
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marwan-at-work I think you need them up if you want to run i.e. the storage tests but you're right - not in development since the storage defaults to mem or fs i think.
Maybe we should have a separate target for setting up the test dependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree - we should have a separate target for test deps. is it cool if we leave these uncommented and do that separation in a follow-up PR?
@@ -62,6 +62,7 @@ func App(config *AppConfig) (*buffalo.App, error) { | |||
return nil, err | |||
} | |||
|
|||
lggr := log.New(env.CloudRuntime(), env.LogLevel()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯 !!! really excited to see these loggers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇
pkg/download/list.go
Outdated
return c.Render(http.StatusNotFound, eng.JSON(err.Error())) | ||
if storage.IsNotFoundError(err) || len(versions) == 0 { | ||
if isProxy { | ||
return c.Redirect(http.StatusMovedPermanently, env.OlympusGlobalEndpointWithDefault("")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we pass in the olympus global endpoint?
also can you add a comment here explaining what this redirect will do to vgo, so we remember?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will make sure I pass it. Will add a comment about redirects as well.
lggr.WithFields(logrus.Fields{ | ||
"module": mod, | ||
"method": "ListHandler.getInfoFromPath", | ||
}).SystemErr(err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this return?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we do return, below :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doh, thanks
|
||
if err != nil || info.typ != sourceGithub { | ||
c.Response().WriteHeader(http.StatusNotFound) | ||
return nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you use c.Error(http.StatusNotFound, errors.New("something"))
here? so we have a message that could be logged at some point in the future. same with the above c.Response()...
calls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arschles I cannot use c.Error Buffalo doesn't do well with logging c.Error
See gobuffalo/buffalo#1171
Either way, we are logging the error above so it won't get away :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, ok - thanks for explaining
@arschles updated the PR but I had to move the Olympus Env Var out of actions to avoid import cycles. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marwan-at-work this is looking 🔥 - some more comments
Makefile
Outdated
docker-compose -p athensdev up -d mysql | ||
docker-compose -p athensdev up -d postgres | ||
# docker-compose -p athensdev up -d mysql | ||
# docker-compose -p athensdev up -d postgres |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree - we should have a separate target for test deps. is it cool if we leave these uncommented and do that separation in a follow-up PR?
lggr.WithFields(logrus.Fields{ | ||
"module": mod, | ||
"method": "ListHandler.getInfoFromPath", | ||
}).SystemErr(err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doh, thanks
|
||
if err != nil || info.typ != sourceGithub { | ||
c.Response().WriteHeader(http.StatusNotFound) | ||
return nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, ok - thanks for explaining
"github.com/gomods/athens/pkg/paths" | ||
"github.com/gomods/athens/pkg/storage" | ||
"github.com/google/go-github/github" | ||
"github.com/marwan-at-work/vgop/semver" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marwan-at-work I remember you saying you had to copy some logic from the go modules tree to verify semvers. Instead of that would you be open to using https://github.com/Masterminds/semver, so you don't have to maintain more code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arschles i looked into this package and they seem to be relaxed on the v
prefix restriction (they allow 1.3.2
while semver.IsValid would not allow it - not sure if there are other inconsistencies between the Masterminds/semver and go/semver - should we just use Masterminds/semver anyway?
// as that server returns an answer that Go expects. | ||
return c.Redirect(http.StatusMovedPermanently, env.GetOlympusEndpoint()) | ||
} else if !isGithubPath(mod) { | ||
c.Response().WriteHeader(http.StatusNotFound) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if there are no versions, this can return an empty list. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arschles returning no versions would cause Go to make an /@latest
which is fine once we have a go get
set up on the Proxy to work with SHAs. Although does Go tip expose a CLI command to retrieve latest
??? This go get
stuff you're doing wouldn't work otherwise 😓
// Go uses the http.DefaultClient which implicitly handles up to 10 reqdirects. | ||
// therefore, it's safe to redirect to whatever server/endpoint we like as long | ||
// as that server returns an answer that Go expects. | ||
return c.Redirect(http.StatusMovedPermanently, env.GetOlympusEndpoint()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marwan-at-work do you happen to know if the redirect is "officially supported" in go get
? I'd like to make sure it's a somewhat properly specified feature of go get
and we're not relying on an implementation detail in the CLI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as long as go get
uses the standard library net/http
DefaultClient (which it does) redirects are officially supported.
sourceVCS | ||
) | ||
|
||
func getInfoFromPath(ctx context.Context, path string) (importInfo, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️ this function, but could we make it more vcs-agnostic? Perhaps we could do a go get -u $path
and list the tags using git tags
(only supporting github for now)?
Longer term, I think we should get this logic moved into the go
toolchain so we can get tags for a module from the CLI. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arschles do you mean only supporting git
or only supporting github
? If only supporting github, then calling the API directly should always work.
But if only supporting git
, then go get
makes sense here. However, what happens when we do go get some/package
and then it's not git
?
Implements the
/list
part of #290