Consider using actions/cache

[embano1]

Is there a particular reason why actions/cache is not included in the workflows?

Besides vendor addressing the module cache in this particular case, persisting the build cache could optimize build times across the org (and dependent repositories) IMHO.

https://github.com/actions/cache/blob/main/examples.md#go---modules

[embano1]

I ran some (non-scientific) experiments with eventing and VSphereSources and could not see a huge performance gain from adding a cache.

From what I can tell this is due to:

1. Using vendor which absorbs a lot of the typical go mod download time (in a test repo without vendor I do see gains as expected)
2. Sharing the cache with different workflows (using same cache key for unit tests, lint, e2e, etc.) leads to a situation where apparently not all Go cached files are uploaded to the cache destination. Sometimes I only saw 5MB cache size compared to 1.2GB in a local run (for pkg mod and gobuild cache)

Haven't looked deeper into the latter, i.e. why the cache is not the similar size I am seeing after a workflow run in the local GOCACHE GOMODCACHE folders.

Closing this issue for now. Apparently, the community is also pushing for actions/setup-go to support caching without an extra step (see actions/setup-go#130).