Upgrading go version and removing go get to download dependencies

[soodpr]

Description
Upgrading go version and removing go get to download dependencies

Issues Resolved
Fixes #106

Check List

• New functionality includes testing.
• New functionality has been documented in the README if applicable.

[jsmartt]

You may have figured this out by now, but the reason your build are failing is because your git commit messages are missing a "signature". See build/validate-dco and HewlettPackard/docker-machine-oneview/CONTRIBUTING.md

I don't think this process provides any value, and it's not a standard process for our other repos, so I'm not sure why it was required here. I'd rather just put these details in a CONTRIBUTING file and let GitHub remind the user to read it. The LICENSE.md file also addresses the legal implications of contributing.
@bobfraser1, any input here?

[patrickdappollonio]

In addition to what @jsmartt mentioned, there's also this:

Performing FMT checks, if any files appear they run gofmt -s -w on each file
test/ov/profile_templates_test.go
test/ov/storage_volume_test.go
make: *** [fmt] Error 1

Some of the files are not properly gofmt-ed which doesn't pass the test. I think @wenlock may have enforced back then format -- which is a good thing -- as part of the testing process.

[patrickdappollonio]

So now since Go was updated, the go vet tool is enforcing more standards, like unkeyed fields. While go vet shouldn't be enforced because it may return false positives -- and this is widely documented -- it's still good to have it on reporting something not okay.

Performing VET checks
./testconfig ./test/ov ./test/icsp ./test/i3s ./liboneview ./rest ./utils
# github.com/HewlettPackard/oneview-golang/test/ov
test/ov/ov_test.go:55: github.com/HewlettPackard/oneview-golang/ov.OVClient composite literal uses unkeyed fields
test/ov/ov_test.go:81: github.com/HewlettPackard/oneview-golang/ov.OVClient composite literal uses unkeyed fields
# github.com/HewlettPackard/oneview-golang/test/icsp
test/icsp/icsp_test.go:61: github.com/HewlettPackard/oneview-golang/icsp.ICSPClient composite literal uses unkeyed fields
test/icsp/icsp_test.go:84: github.com/HewlettPackard/oneview-golang/icsp.ICSPClient composite literal uses unkeyed fields
# github.com/HewlettPackard/oneview-golang/test/i3s
test/i3s/i3s_test.go:41: github.com/HewlettPackard/oneview-golang/ov.OVClient composite literal uses unkeyed fields
test/i3s/i3s_test.go:67: github.com/HewlettPackard/oneview-golang/i3s.I3SClient composite literal uses unkeyed fields
make: *** [vet] Error 1

In this case, all the "errors" (which aren't technically errors) above are because you're calling a structure, say icsp.ICSPClient{} which may have, say, a Content string attribute inside... Then the code is calling it this way icsp.ICSPClient{"ABC123"}, which is working Go code.

The go vet tool though will say to not use unkeyed fields, but rather specify that the value belongs to Content, so rather than writing icsp.ICSPClient{"ABC123"}, you would write icsp.ICSPClient{Content:"ABC123"} (note the Content variable named inside the curly braces).

Again, this is not an error per se, it's just "best practices". From the Go docs:

Vet uses heuristics that do not guarantee all reports are genuine problems, but it can find errors not caught by the compilers.

[bobfraser1]

@jsmartt Yes, there is a check for 'signed-off-by'. Just add -s to your commits and the check should pass. We should all get in the habit of doing this always. I reviewed with legal and if we are Apache 2.0, include the DCO, and require 'signed-of-by' for all commits, then we can accept 3rd party pull requests with no further legal requirements. There are a number of repos I have already modified to include this. I will update the CONTRIBUTING.md in this project.

We could remove the DCO check script in the build for now. I do like the script as it automates the process of making sure commits are 'signed off'. If we continue to use the script we should make it generic and not refer to Docker or Docker resources. Anyway this check may be overkill. The reviewer can just look in the commit history and see if the commits are signed of.

Finally, we are not actually requiring a signature. GitHub does have that feature. It requires GPG keys and is very intrusive. I checked, we don't do that. So we require sign off. Just putting this out there as I have been confused on this topic as have others I talk to.

[patrickdappollonio]

Looks good to me!

[soodpr]

@patrickdappollonio , @jsmartt , @bobfraser1 - Thanks guys for your valuable comments and suggestions that helped me to resolve all the issues.