wip: Move to Go modules

[amshinde]

Move from go dep to go modules.

Fixes #1331

[jodh-intel]

lgtm

[jodh-intel]

Nice. Could you add a check like this to https://github.com/kata-containers/tests/blob/master/.ci/static-checks.sh for repos that are using go modules? Yes, I know the check is already here, but having such a central and PR-gating check will hopefully keep all the repos protected.

[amshinde]

@jodh-intel I have finally addressed this after my unexpected interim break.
I have opened a PR in the tests repo to account for go modules.
See: kata-containers/tests#1880

[jodh-intel]

Thanks @amshinde.

[ganeshmaharaj]

@amshinde Is the plan to get runtime moved while we move rest of the repos? In that case, tests repository needs to be bostered to run go mod verify against dep check for just these repos.

[jodh-intel]

@amshinde, @ganeshmaharaj - please can we document the plan on kata-containers/kata-containers#42 to allow others to understand (and comment on) it.

[amshinde]

/test

[amshinde]

@jodh-intel Will update the issue.

[caoruidong]

ping @amshinde

[umarcor]

Hi @amshinde, @jodh-intel! Coming from #1420, I'm sorry to be the one bringing bad news here...

Context:

• Currently, this repository retrieves the tests repo with 'go get' and expects it to be available in GOPATH/src/github.com/kata-containers/tests. However, in any environment where go modules are enabled, go get will NOT download sources of packages in that path. This is why this PR will fail when go modules are enabled in Travis: https://travis-ci.com/umarcor/kata-runtime/jobs/231319730. See Migrate to go modules (deprecate 'vendor') #1420 (comment).
• With go modules, 'vendor' is expected not to be required and there is no idiomatic way to properly 'mix' sources available in the modules caches and those in 'vendor'. This is related to modules: Verification for go modules tests#1880 (comment).
  • Any build with go modules should be reproducible, as long as remotes are not gone. This is the only use case of 'vendor' in the new environment: a backup, just in case some of the remotes fail. As a result, 'vendor' should not be included in the VCS. In any case, vendor packages could be distributed as tarballs for users with very specific requirements to have them.
  • By the same token, build commands need to be specifically forced to use the vendor folder.

Therefore, I think that this PR should ensure that go modules are not used, except for running go mod vendor.

[WeiZhang555]

I think go mod vendor can be an option. How about we only use go mod to manage our "vendor" dir instead of remove whole "vendor" from the repo?

[umarcor]

I think go mod vendor can be an option. How about we only use go mod to manage our "vendor" dir instead of remove whole "vendor" from the repo?

That's a temporal solution that will only work as long as go modules are optional. Nevertheless, as commented, this approach would require:

• this PR should ensure that go modules are not used, except for running go mod vendor.
• build commands need to be specifically forced to use the vendor folder.

[jcvenegas]

@amshinde ping this needs rebase

[raravena80]

@amshinde any updates on this PR? Thx!

[HZ89]

@amshinde any updates on this PR? Thx!

[amshinde]

I'll revisit this PR this week.

[raravena80]

@amshinde any updates? Thx.

Your weekly Kata herder.

[raravena80]

@amshinde ping 😄

[bergwolf]

Currently, this repository retrieves the tests repo with 'go get' and expects it to be available in GOPATH/src/github.com/kata-containers/tests. However, in any environment where go modules are enabled, go get will NOT download sources of packages in that path. This is why this PR will fail when go modules are enabled in Travis: https://travis-ci.com/umarcor/kata-runtime/jobs/231319730. See #1420 (comment).

We should not use the new go get to download code or binary inside a go module directory, -- it would fetch the code and add it to your go.mod dependency. git clone is your friend ;)

And kindly ping @amshinde from your Kata Herder this week ;)

[umarcor]

We should not use the new go get to download code or binary inside a go module directory, -- it would fetch the code and add it to your go.mod dependency. git clone is your friend ;)

@bergwolf, thanks for acknowledging this point. I've been trying to make it clear for almost a year now.. #1420, #1413. I believe that's the critical issue that is preventing any practical movement towards go modules.

[raravena80]

@amshinde @bergwolf @umarcor ping.

[umarcor]

See #1420 (comment).