Add support for cache per job for multiple repo/jobs workflows

Description: Currently a cache option does not allow setting a target cache name. So if you have a setup action like one below in multiple jobs in the same workflow, you will end-up in situation that only the first job is able to create a new cache item.

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'
          cache: maven

Now if you think about complex workloads where for example in one job I build one component and in other I build another component, the second job will never be able to create/update the cache, and ends up reporting:

Post job cleanup.
Cache hit occurred on the primary key setup-java-Linux-maven-6c2c8a559e1cd40e1d894833707e2873888f46c5461f3a626c93ef3c40ba0ca5, not saving cache.

We are hitting this issues where we have a multi-repository checkout, and build is split in multiple jobs. Only the first job caches the dependencies correctly. Even in a mono-repo scenarios you might have different independent projects in the same repo that you want to build with some dependency-order.

The simple requirement would be to add a cache name prefix or something like this, so that I would end-up having different caches used in different jobs.

Task version: actions/setup-java@v3

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
Public example: https://github.com/stargate/stargate/actions/workflows/apis-v2.yaml

• First job Coordinator build is the only one creating a cache item
• The Unit tests that runs unit tests on different pom.xml is never able to cache dependencies

Expected behavior: Would like to be able to either update cache or specify a different cache name.

Actual behavior: Cache not saved/updated.

[ivansenic]

I perfectly understand that the builtin cache should be zero-config and that adding a cache action myself is easy. But have you considered how many people might be doing this wrong? My self as well for example… I was sure that this auto-built caching support would be handling everything, even in different jobs… But in fact my dependencies are not cached and I have longer running actions because of that… Now think on all GitHUb users and how much this “misunderstood” usage costs GitHub a year and how much it costs the environment…

I gave feedback that I consider valuable, because I believe in the feedback-driven development… It’s up to you to decide if this goes into roadmap or not…

I am willing to help… I can set whatever you need, I can even implement the feature myself… Just give me a green light!

[dmitry-shibanov]

Hello @ivansenic. Thank you for your report. We’ll investigate the issue.