Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add extra cache key for multiple jobs on the same pom, but a different part #705

Open
DavyLandman opened this issue Nov 11, 2024 · 1 comment
Labels
feature request New feature or request to improve the current logic

Comments

@DavyLandman
Copy link

Description:
I want to optionally annotate the cache-key with an extra description, such that if we have multiple jobs, that all only have a partial execution of the pom, they can still get a full cached .m2 repo.

Something like:

      - name: Set up JDK
        uses: actions/setup-java@v4
        with:
          java-version: ${{ matrix.jdk }}
          cache: 'maven'
          cache-key-prefix: 'test'

Justification:
For example

  • runner 1 only runs mvn test (possibly in a matrix)
  • runner 2 triggers some lints with mvn check (runs in parallel to runner 1)
  • runner 3 runs the build & publish action after 1 and 2 are done

Right now, for a new pom the following happens:

  1. runner 1 sees a new checksum, so it doesn't download an old cache, and then starts the regular.
  2. at the end of runner 1, the current .m2 repo, that is only filled with the plugins to run mvn test gets submitted as the cache for this specific pom.xml
  3. runner 2 actually races with this submission, with again a sub-optimal filled .m2 repo
  4. runner 3 starts, downloads the cache of runner 1 or runner 2
  5. the maven command that is run has to download quite some dependencies not needed for testing or checking.
  6. as runner 3 stops, the java-action plugin does not upload this .m2 repo, as there was a cache hit when it started.

In situations like this, every run afterwards will have runner 3 re-download dependencies, and runner 1 or 2, depending on who lost the race. The current workaround is to add some spaces to the pom.xml just before the setup-java action is run.

Are you willing to submit a PR?
Yes, if I get an indication if such a PR has a chance of getting merged, I'm willing to allocate some time to add this.

@DavyLandman DavyLandman added feature request New feature or request to improve the current logic needs triage labels Nov 11, 2024
@gowridurgad
Copy link

Hi @DavyLandman,
Thank you for the feature request. We'll investigate it and get back to you as soon as we have updates.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

2 participants