Skip to content
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

Closed
wants to merge 13 commits into from
Closed

initiate go module #1150

wants to merge 13 commits into from

Conversation

wingyplus
Copy link
Contributor

@wingyplus wingyplus commented Sep 11, 2019

Updates #1070

@CLAassistant
Copy link

CLAassistant commented Sep 11, 2019

CLA assistant check
All committers have signed the CLA.

@codecov-io
Copy link

codecov-io commented Sep 11, 2019

Codecov Report

Merging #1150 into master will decrease coverage by 9.54%.
The diff coverage is n/a.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
lib/options_tls_go1_13.go 0% <0%> (-100%) ⬇️
stats/statsd/common/config.go 0% <0%> (-100%) ⬇️
stats/statsd/common/api.go 0% <0%> (-100%) ⬇️
lib/fsext/cacheonread.go 0% <0%> (-100%) ⬇️
lib/netext/httpext/transport.go 0% <0%> (-96.16%) ⬇️
lib/netext/httpext/response.go 0% <0%> (-92.16%) ⬇️
lib/netext/httpext/request.go 9.46% <0%> (-87.58%) ⬇️
js/modules/k6/http/file.go 0% <0%> (-83.34%) ⬇️
lib/netext/httpext/digest_transport.go 0% <0%> (-80%) ⬇️
lib/netext/httpext/httpdebug_transport.go 0% <0%> (-75%) ⬇️
... and 41 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a2077dd...e5914fc. Read the comment docs.

Copy link
Contributor

@cuonglm cuonglm left a 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.

@wingyplus
Copy link
Contributor Author

wingyplus commented Sep 11, 2019

Should we need to keep it for Go1.12 ci pipeline. Or use dep ensure to fetch dependencies before running test?

@cuonglm
Copy link
Contributor

cuonglm commented Sep 11, 2019

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:

go mod edit -go=1.12

before running the test.

@na--
Copy link
Member

na-- commented Sep 11, 2019

We are switching to go module, then I think we can drop vendor directory, and setup proper CI/CD flow to adopt go module.

Why do you want to drop /vendor? I'd be very reluctant to do so, even with the new official Golang module mirror. I like the safety, predictability, and visibility of having all of the k6 dependencies in our own repo. The visibility is especially useful in helping us avoid very fat or needless dependencies, so that we don't unnecessarily explode the footprint of code we depend on...

Should we need to keep it for Go1.12 ci pipeline. Or use dep ensure to fetch dependencies before running test?

Go modules should work just fine in Go 1.12, we shouldn't need dep there 😕

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...

@cuonglm
Copy link
Contributor

cuonglm commented Sep 11, 2019

Go modules should work just fine in Go 1.12, we shouldn't need dep there

The go.mod only allows 1 go version.

If we do want to keep vendor directory, then go1.12 pipeline can be run with -mod=vendor 🤔

@na--
Copy link
Member

na-- commented Sep 11, 2019

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 -mod=vendor if we want both go modules and vendoring... Or, more likely, on GOFLAGS=-mod=vendor. Some links if anyone else wants to follow the related discussions:

@na-- na-- mentioned this pull request Sep 11, 2019
@cuonglm
Copy link
Contributor

cuonglm commented Sep 11, 2019

@na-- I think we should only use go module for vendor management only, so the process will be:

  • go mod tidy
  • go mod vendor

Then in CI/CD, we will explicitly set GO111MODULE=off.

@na--
Copy link
Member

na-- commented Sep 11, 2019

👍 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...

@wingyplus
Copy link
Contributor Author

@cuonglm @na-- I think we can use go module mode on go1.12 by using enabling GO111MODULE. This can be the same as setting on go1.13.

@cuonglm
Copy link
Contributor

cuonglm commented Sep 11, 2019

@cuonglm @na-- I think we can use go module mode on go1.12 by using enabling GO111MODULE. This can be the same as setting on go1.13.

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.

@wingyplus
Copy link
Contributor Author

I found test failing on go1.13 in the current build of this pr:

--- FAIL: TestSentReceivedMetrics (36.73s)
    --- FAIL: TestSentReceivedMetrics/group (0.00s)
        --- FAIL: TestSentReceivedMetrics/group/SentReceivedMetrics_script[3]_case[4](25,2) (3.11s)
            engine_test.go:624: noReuseReceived=28325.000000 is greater than reuseReceived=28329.000000

Not sure is it flaky test?

@wingyplus
Copy link
Contributor Author

@cuonglm I think we edit go.mod to go 1.12 at minimum version to support both version in CI. And we'll bump to go 1.13 when go 1.14 release. What do you think?

@cuonglm
Copy link
Contributor

cuonglm commented Sep 11, 2019

@cuonglm I think we edit go.mod to go 1.12 at minimum version to support both version in CI. And we'll bump to go 1.13 when go 1.14 release. What do you think?

Ah, sound good 👍

And also, the test false is flaky one, see ##1149

@wingyplus
Copy link
Contributor Author

@cuonglm Thanks for your pointing out an issue. I'll wait until it fix and rebase to test again if #1149 got merged to master. :)

@wingyplus
Copy link
Contributor Author

test-prev-golang task work as expect 🎉

@na-- na-- added this to the v0.26.0 milestone Sep 13, 2019
@na-- na-- modified the milestones: v0.26.0, v0.27.0 Oct 10, 2019
@na-- na-- modified the milestones: v0.27.0, v0.28.0 May 21, 2020
@thinkerou
Copy link
Contributor

hi any updates? merged before #1007 ? thanks!

@na--
Copy link
Member

na-- commented May 27, 2020

@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.

@thinkerou
Copy link
Contributor

@na-- got it, thank your reply!

@imiric
Copy link
Contributor

imiric commented Aug 14, 2020

@wingyplus Thanks for your work on this, but we did it from scratch in #1584, which is now merged, so closing this.

@imiric imiric closed this Aug 14, 2020
@wingyplus wingyplus deleted the gomod branch August 14, 2020 11:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants