search

gradle / gradle-build-action

Execute your Gradle build and trigger dependency submission
https://github.com/marketplace/actions/gradle-build-action
MIT License
679 stars 97 forks source link

Added AWS S3 bucket support #754

Closed gmazzo closed 1 year ago

gmazzo commented 1 year ago

Addresses #752 by first decoupling the cache usage from GitHub API, and then introducing a new provider for AWS S3.

This has not been tested (yet) nor added tests for it. Looking for early feedback if this contribution will be desired.

bigdaz commented 1 year ago

Thanks for the PR @gmazzo. I think it makes sense to support alternative cache backends, if feasible. However, I don't think an S3 implementation will be so simple. There are at least 2 features of the GitHub Actions cache that you would need to emulate in order to achieve the same behaviour:

  1. Cache entries from different git branches are isolated. Only cache entries save by the same branch or a base branch. See here for more details: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache
  2. Cache entries are restored based on partial match of keys. So you can supply a restore key like foo-bar and it will match an entry saved with key foo-bar-1234. The gradle-build-action relies on this functionality to restore the Gradle User Home for a prior workflow run.

I presume that you could achieve similar results with S3, although I'm not familiar with the API. If you want to continue with this, I suggest that you enable S3 cache backend and run the ci-quick-check.yml workflow in your fork. This should give you an idea of what's working.

gmazzo commented 1 year ago

I suggest that you enable S3 cache backend and run the ci-quick-check.yml workflow in your fork. This should give you an idea of what's working.

Thanks for the feedback and this tip. I'll keep this on my personal backlog for now because as you pointed out it probably won't be so easy to implement.