Allow setting cache key for multiple targets (same go.mod)

[hermanbanken]

Description:
Any larger project with multiple cmd might build multiple binaries with distinct sets of dependencies. As #259 already indicated, those workflows will fight for the cache. Given workflow A & B, if any of those two finishes and is cached, any subsequent build reuses the same cache. Even if the build of B has a completely different go-build cache state.

Justification:
This is specifically a problem, when building both (tiny) plugins, and large server binaries (both in different pipelines). This requires a monorepo, because the plugin must use the exact same module versions, so the go.mod/go.sum files are the same, therefore cache-dependency-path is not an option.

Both should use the same go env GOMODCACHE (go/pkg/mod) but different go env GOCACHE (go-build).

Are you willing to submit a PR?
Should I create a PR for an optional field that can be set to be included in the cache key?

I think something like the following would suffice:

# workflow job A
steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-go@v3
    with:
      go-version: '1.19'
      cache: true
      cache-key-suffix: toolA
  - run: go run cmd/toolA/

# workflow job B
steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-go@v3
    with:
      go-version: '1.19'
      cache: true
      cache-key-suffix: toolB
  - run: go run cmd/toolB/
 

[e-korolevskii]

Hello @hermanbanken. Thank you for your report. We'll investigate the feature request.

[dmitry-shibanov]

Hello @hermanbanken. I'm going to close the issue because according to the ADR the goal of caching is to provide basic cases for its usage. If you need more flexibility you should use actions/cache.