Switch from vendoring to Go modules

[jlucktay]

The go.mod file for this project already specifies Go v1.15, and modules are recommended production-ready as of v1.14.

There don't seem to be any private dependencies to complicate permissions and such in the build/test pipeline, so IMHO make the jump while the jumping is good. 🙂

[gernest]

I'm confused. We already use go.mod.

Any arguments against go mod vendor? . I find convenient in ci or any env to git clone && go build without extra remote api calls and package resolution.

One advantage of vendor is when doing development, for instance you depend on foo something goes wrong on your project and you need quick printf to see what is happening in foo because foo is a black box with no enough instrumentation for logging.

With vendored foo I can modify it quickly and get feedback right away. Without vendor I can't do anything since the pkg/mod cache is immutable I will need to use delve maybe and it is slow and complicates my workflow

If you spend enough time debugging go projects in the go.mod era, vendor directory is a godsend.

Happy to hear other opinions on this topic.

[asoorm]

I started using vendor directory for performance reasons in the CI environment. It cuts test & build time by several minutes. Alternative would be to use caching inside GitHub actions + remove vendor directory - but reverting feels like it just achieves a similar thing without clarity of the actual benefits it will bring.

[asoorm]

Closed by #296