R4R: Added goimports tool to get_tools. Fixed get_tools build.

[greg-szabo]

Issue: #2766
Please see old PR #2767 for discussion.

• Targeted PR against correct branch (see CONTRIBUTING.md)

• Linked to github-issue with discussion and accepted design OR link to spec that describes this work. Issue: It would be better to use goimports to organize imported packages #2766

• Wrote tests (tested Makefile on Linux)

• Updated relevant documentation (docs/)

• Added entries in PENDING.md with issue #

• rereviewed Files changed in the github PR explorer

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[greg-szabo]

So, the other PR has 212 files changed, mostly because the Go files were reformatted with goimports. That leads to oversight: I didn't see the format target addition at first. Fixed it in a second commit to this PR.

We should run the goimports tool on the Go files in a separate PR that does nothing else, to keep it more manageable.

[greg-szabo]

Please not that the PHONY target does not contain the targets for tool building. This way Make will only run the targets if the files are missing.

[codecov]

Codecov Report

Merging #2889 into develop will increase coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #2889      +/-   ##
===========================================
+ Coverage    56.82%   56.86%   +0.04%     
===========================================
  Files          120      120              
  Lines         8298     8298              
===========================================
+ Hits          4715     4719       +4     
+ Misses        3265     3261       -4     
  Partials       318      318

[yutianwu]

here is a issue about goimports you can refer to:
golang/go#20818

but the change have been reverted, it's up to you to use the latest version or the previous version.

[greg-szabo]

Oh, so you say that we might not want to use the latest commit from goimports? The current assumption (the easy path) was to use go get and get the latest master from that repo. If we have to implement picking specific commits from the golang.org repo, we might end up in a world of pain. But I'll think about it.

[yutianwu]

Oh, so you say that we might not want to use the latest commit from goimports? The current assumption (the easy path) was to use go get and get the latest master from that repo. If we have to implement picking specific commits from the golang.org repo, we might end up in a world of pain. But I'll think about it.

imho, I think the reverted version is better if you don't have other concerns.