Should we set up a GitHub action for golint?

[olliefr]

I've just run golint on the branch that I was working on and (ignoring the missing documentation), these are the results:

❯ golint ./... | grep -v "or be unexported"

agent/component/component.go:39:6: type name will be used as component.ComponentType by other packages, and that stutters; consider calling this Type
agent/component/core.go:34:6: type name will be used as component.ComponentCore by other packages, and that stutters; consider calling this Core
agent/component/core.go:211:1: context.Context should be the first parameter of a function
agent/component/apiserver/api_server.go:34:1: context.Context should be the first parameter of a function
agent/component/natsserver/nats.go:64:1: context.Context should be the first parameter of a function
agent/component/worker/worker.go:44:1: comment on exported type Worker should be of the form "Worker ..." (with optional leading article)
agent/component/worker/worker.go:51:1: context.Context should be the first parameter of a function
api/core/context.go:30:1: comment on exported method ResourceState.Insert should be of the form "Insert ..."
api/core/data.go:68:1: comment on exported method Data.ToResourceBlockJSON should be of the form "ToResourceBlockJSON ..."
api/v1/run.go:52:1: comment on exported type RemoteBlockSpec should be of the form "RemoteBlockSpec ..." (with optional leading article)
bubbly/query.go:17:1: comment on exported var ErrNoResourcesFound should be of the form "ErrNoResourcesFound ..."
bubbly/query.go:23:2: struct field Id should be ID
client/client.go:20:1: comment on exported type Client should be of the form "Client ..." (with optional leading article)
client/nats_test.go:20:7: don't use ALL_CAPS in Go names; use CamelCase
client/resource.go:48:1: receiver name h should be consistent with previous receiver name c for httpClient
cmd/agent/agent.go:49:6: type name will be used as agent.AgentOptions by other packages, and that stutters; consider calling this Options
cmd/apply/apply.go:34:6: type name will be used as apply.ApplyOptions by other packages, and that stutters; consider calling this Options
cmd/get/get.go:46:6: type name will be used as get.GetOptions by other packages, and that stutters; consider calling this Options
cmd/schema/schema.go:10:1: comment on exported function NewCmdSchema should be of the form "NewCmdSchema ..."
cmd/schema/apply/apply.go:33:6: type name will be used as apply.ApplyOptions by other packages, and that stutters; consider calling this Options
interval/worker.go:55:6: type name will be used as interval.IntervalPool by other packages, and that stutters; consider calling this Pool
interval/worker.go:71:1: comment on exported method Pool.Remove should be of the form "Remove ..."
interval/worker.go:319:1: context.Context should be the first parameter of a function
store/postgres_graphql.go:497:9: if block ends with a return statement, so drop this else and outdent its block
store/triggers.go:57:94: exported func HandleTriggers returns unexported type store.dataTree, which can be annoying to use

This contradicts our Contributing Guide, which states that

All code should be free from errors when running golint and go vet

Which made me think...

❓ The Burning Question

Should we add a check to GitHub Actions to run those two tools on every incoming PR?

My vote is: ✔️ Yay

Please let me know what you think and I'll raise an issue, if we all agree on that.