-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
initiate go module #1150
initiate go module #1150
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1150 +/- ##
==========================================
- Coverage 73.61% 64.06% -9.55%
==========================================
Files 144 133 -11
Lines 10527 10091 -436
==========================================
- Hits 7749 6465 -1284
- Misses 2321 3207 +886
+ Partials 457 419 -38
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.
We are switching to go module, then I think we can drop vendor directory, and setup proper CI/CD flow to adopt go module.
Should we need to keep it for Go1.12 ci pipeline. Or use dep ensure to fetch dependencies before running test? |
I think we can completely remove dep and vendor. For go1.12 pipeline, we can run:
before running the test. |
Why do you want to drop
Go modules should work just fine in Go 1.12, we shouldn't need Also, please don't actually update the dependencies when switching to go modules - it makes this PR very difficult to review. The dependency update should be in a separate pull request, or at the very least, in a separate commit... |
The If we do want to keep vendor directory, then go1.12 pipeline can be run with |
If we have vendor (and I still see no reason to remove it), we should probably use it for all builds - 1.12, 1.13 and so on. For one, given that CI systems will build the project in fresh containers, using the local vendored files will be faster than retrieving them over the network every time... I had to read through a bunch of Go issues, and to be honest, I'm far from satisfied with how tacked on and poorly supported vendoring is in the go modules world 😞 I loosely followed the Go modules saga, but I never realized that backwards incompatibility, I just assumed things would work as they used to, backwards compatibility guarantees and all... 😞 In any case, it seems like most issues will be fixed in Go 1.14, but until then, we'd have to rely on things like
|
@na-- I think we should only use go module for vendor management only, so the process will be:
Then in CI/CD, we will explicitly set |
👍 seems reasonable, it may be an easier workaround until vendoring is properly supported in Go 1.14, but as I've seen today, I'm far from an expert in Go modules... |
Yes, you can. But the issue is that go.mo specify go1.13 version, so without editing go.mod, building using go1.12 will fail. That's why I said it's better to use go module for vendoring only, then in CI/CD, just turn off GO111MODULE and build using vendor. |
I found test failing on go1.13 in the current build of this pr:
Not sure is it flaky test? |
@cuonglm I think we edit go.mod to |
|
hi any updates? merged before #1007 ? thanks! |
@thinkerou, moving to use go modules will definitely have to wait until after #1007 is merged... Maybe we'll do it in conjunction with #959. Also, we want to keep vendoring our dependencies, so we had to wait for Go 1.14 (see linked golang issues in #1150 (comment)), and this is something that this PR doesn't address, so when the time comes, we'll probably close this and make a new PR. |
@na-- got it, thank your reply! |
@wingyplus Thanks for your work on this, but we did it from scratch in #1584, which is now merged, so closing this. |
Updates #1070