.github: Add a sanity check for Go packages

[timflannagan]

Add a vendor check to the testing actions that runs $(make) vendor and
verifies that the vendor directory is up-to-date and no git diff has
been produced.

Description of the change:

Motivation for the change:

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Docs updated or added to /docs
• Commit messages sensible and descriptive

[codecov]

Codecov Report

Merging #596 (1e490c7) into master (607d373) will not change coverage.
The diff coverage is 50.00%.

@@           Coverage Diff           @@
##           master     #596   +/-   ##
=======================================
  Coverage   48.80%   48.80%           
=======================================
  Files          90       90           
  Lines        6276     6276           
=======================================
  Hits         3063     3063           
  Misses       2528     2528           
  Partials      685      685           

Impacted Files	Coverage Δ
pkg/lib/bundle/interfaces.go	0.00% <0.00%> (ø)
...qlite/migrations/006_associate_apis_with_bundle.go	60.57% <ø> (ø)
pkg/sqlite/db.go	50.00% <50.00%> (ø)
pkg/server/server.go	43.58% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 607d373...1e490c7. Read the comment docs.

[timflannagan]

/retitle .github: Add a sanity check for Go packages

[timflannagan]

/retest

[timflannagan]

/test all

[timflannagan]

I can also just split this out to run the linting check and remove that lint make target:

goimports -w $(find . -name '*.go' -not -path "./vendor/"

And then have the git diff ... check in another step. Open to suggestions on how to best organize this, or whether we're fine with throwing this under a single step.

[joelanford]

Just my personal preference, but I like to have make targets that encapsulate the github jobs so that things are eay to reproduce locally with as little hassle as possible, including getting and using the correct version of whatever tool the Makefile depends on.

Not something I would hold this up for at all, but in SDK we ended up with this script and then make targets would call it like this: https://github.com/operator-framework/operator-sdk/blob/4e16f401032ca61f1e57203840dbc303de365f42/Makefile#L126

It was nice because:

1. If we ever needed to switch to a different CI runner (which happened three times between Travis/Openshift CI and then to GitHub actions), it was pretty simple.
2. Anyone calling the make target is using the version specified, rather than whatever is on their path.
3. No one has to worry about figuring out how to get the various tools in the first place.

Whenever we had a new tool dependency, it was pretty easy to tack it onto the end of that case block in the fetch script.

[timflannagan]

Yeah, absolutely that makes a lot of sense. I'll dive into those links some more - I think I would prefer getting something merged sooner-than-later just because this PR also changes files after running goimports locally, so it seems like some editors aren't fully set up to format on save. Going forward, and there's already a TODO in this PR about running go vet ... as well, we should probably aim towards emulating some of that SDK workflow.

[joelanford]

/lgtm

[timflannagan]

/retest

[timflannagan]

/retest

[ecordell]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ecordell, timflannagan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ecordell]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment