Switch to using go modules

[techknowlogick]

Description

Switches from dep to use go modules.

Motivation and Context

By switching to go modules it would bring dependency management to align with go ecosystem.
Fixes #160

• I have raised an issue to propose this change (required)

How Has This Been Tested?

make build test succeeded.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s
• I have added tests to cover my changes.
• All new and existing tests passed.

[techknowlogick]

Sorry for the multiple commits.

I've been trying to debug, and travis is doing weird things with the vendor/modules.txt even before the docker build has started. In my fork I have a test branch where I've added ls vendor as the first command run, and modules.txt is missing, hence the errors in docker build.

I've reached my quota for debugging tonight, but hopefully I'll be recharged later and can revisit this. Another option is to remove the vendor dir as a whole, but I'm trying to solve this with making as few changes from existing workflow as possible.

[techknowlogick]

Ah, I shouldn't debug so late at night. I wasn't actually adding in the modules.txt file which was what was missing. This PR is now good to go.

[alexellis]

Why did so many files change for a dep - mod update?

[alexellis]

@techknowlogick

[techknowlogick]

Why did so many files change for a dep - mod update?

Primary cause is github.com/sirupsen/logrus this is due to the reference having the username uppercase, but due to conflicts I had to lowercase it as well as update the module. This had a knock on effect of updating other modules that it depends upon. As well, yaml import was not defined in the gopkg.toml, and only the lock, and go mod prefers to use semver references as much as possible.

Note: I updated as few things as possible, for example github.com/google/go-github is still at v17 whereas it has reached v32 recently.

[techknowlogick]

This PR doesn't adhere to the Update to Go 1.13 (no higher) requirement from https://trello.com/c/duCUKQPe/161-migration-to-go-modules-for-all-projects so I will update this PR with that in mind.

[alexellis]

Thank you - this PR is wanted. @LucasRoesler bumped into something similar with logrus and faas/faas-cli.

[alexellis]

Approved

[alexellis]

FYI this didn't build for me after merging into master:

go: extracting github.com/Sirupsen/logrus v1.7.0
go: github.com/alexellis/derek/build/derek/handler imports
	github.com/Sirupsen/logrus: github.com/Sirupsen/logrus@v1.7.0: parsing go.mod:
	module declares its path as: github.com/sirupsen/logrus
	        but was required as: github.com/Sirupsen/logrus

What should I do?

[alexellis]

github.com/alexellis/derek/build/derek/handler <- interesting

The ./build folder is generated by OpenFaaS, and the go toolchain is picking it up, when it shouldn't.

I couldn't find a way to exclude a folder from go mod tidy.

[LucasRoesler]

could it be a file system case-sensitivity issue?

i don't understand the statement about handler why would you need to run go mod tidy at that point? are you talking about local builds and then committing?

[alexellis]

An older Derek version was in ./build/ from running faas-cli build earlier. Go modules can't seem to figure out what code to ignore and what to build.