Closed hfhbd closed 1 year ago
As described here and here, the GitHub Actions cache is designed so that workflows on different branches cannot share cache entries. Only caches written from the same branch or from the main
branch can be read.
So the merge queue branch should be able to read cache entries written by a main
workflow. Why do you suspect that "but this branch does not reuse the existing Gradle cache"?
Yes, I am aware of the current behavior: reusing the cache from the main branch so I did expect the same behavior when using merge group: using the cache from the main branch. But this expected behavior didn’t match the current execution which does not use the cache from the main branch.
I don't understand why a workflow on a merge queue branch isn't able to access cache entries written on the main
branch. Is this a public project? Are you able to share more details, like the caching report for the main and merge-queue workflow jobs?
Here's what I would expect to see:
Seed build in 'main':
Consuming build in merge queue:
I rechecked the repo with merge-group enabled and it does work now as expected. Maybe it was a GitHub issue fixed in the mean time.
BTW I also tried the new GitHub dependency submission feature and it works really nice!
Thanks so much for rechecking, and your feedback on dependency-submission. Please let me know if you have any issues or suggestions.
GitHub added a new merge groups feature, which is in Beta: https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta/
Docs: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue
Under the hood, GitHub creates a new branch, but this branch does not reuse the existing Gradle cache, thus resulting into longer builds. Sample: