-
Notifications
You must be signed in to change notification settings - Fork 649
internal/report: make openSourceFile cognizant of Go modules #612
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
internal/report: make openSourceFile cognizant of Go modules #612
Conversation
odeke-em
commented
Mar 21, 2021
Codecov Report
@@ Coverage Diff @@ ## master #612 +/- ## ========================================== + Coverage 66.94% 66.97% +0.02% ========================================== Files 78 78 Lines 14378 14388 +10 ========================================== + Hits 9626 9636 +10 Misses 3892 3892 Partials 860 860
Continue to review full report at Codecov.
|
d11e9de to
d6a7932
Compare
This change adds $GOPATH/pkg/mod as a possible base to search from given that Go modules have been the norm since Go1.11 and we are currently at Go1.16/1.17, hence support for Go modules. Fixes google#611
d6a7932 to
075f40d
Compare
aalexand
commented
Mar 21, 2021
@odeke-em Is it possible to add a test that fails before the the change and passes after?
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.
An alternative would be to somehow make sure that the SourcePath field in options is set correctly earlier?
And if it is the case that all/most Go users are using "go tool pprof" then perhaps we can just arrange for the Go invocation code to pass the right source path settings? Or are you worried about "pprof" invocations that are not via "go tool pprof"?
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.
Perhaps nitpicking slightly, but this is not entirely correct; the only way to reliably find these out would be to run go env -json GOMODCACHE GOROOT.
Using just os.Getenv("GOPATH") will not see if the user set up their own GOMODCACHE, nor will it work with env vars set with go env -w.
Codecov Report
✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.97%. Comparing base (cbba55b) to head (075f40d).
Additional details and impacted files
@@ Coverage Diff @@ ## main #612 +/- ## ========================================== + Coverage 66.94% 66.97% +0.02% ========================================== Files 78 78 Lines 14378 14388 +10 ========================================== + Hits 9626 9636 +10 Misses 3892 3892 Partials 860 860
☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.
🚀 New features to boost your workflow:
- ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
This change adds $GOPATH/pkg/mod as a possible base to search
from given that Go modules have been the norm since Go1.11 and
we are currently at Go1.16/1.17, hence support for Go modules.
Fixes #611