snazy opened a new pull request, #4518:
URL: https://github.com/apache/polaris/pull/4518

   This reverts #4512, commit e7ebe8dab2a67c4db908d1f73c222efd18d2a7cf.
   
   Version 6 of gradle/actions changes the licensing model for the default 
caching behavior used by setup-gradle. The action repository is still mostly 
MIT licensed, but the default "enhanced" caching provider uses the [proprietary 
gradle-actions-caching](https://github.com/gradle/actions/blob/v6.1.0/licenses/gradle-actions-caching-license.txt)
 component.
   
   Gradle 
[documents](https://github.com/gradle/actions/blob/v6.1.0/DISTRIBUTION.md#3-usage-tiers)
 enhanced caching for public repositories as free, and private repository use 
as currently available in a free preview. The same documentation also says 
Gradle plans usage-based pricing for undefined "large-scale commercial 
organizations". Use of the proprietary caching component is governed by 
[Gradle's Terms of 
Use](https://gradle.com/legal/gradle-technologies-terms-of-use/), which may 
change over time.
   
   Version 6 also provides an opt-in 
["basic"](https://github.com/gradle/actions/blob/v6.1.0/docs/setup-gradle.md#basic-caching)
 caching provider under the MIT license, but it is not equivalent to the 
default enhanced provider. Basic caching uses actions/cache directly and lacks 
[enhanced](https://github.com/gradle/actions/blob/v6.1.0/docs/setup-gradle.md#enhanced-caching)
 caching's fine-grained Gradle User Home caching, intelligent cleanup, 
deduplication, or restore-key behavior. For Polaris CI, especially the 
incremental cache workflow, that would likely mean lower cache reuse and more 
cache growth over time.
   
   This is difficult for Polaris because contributors may run CI in private 
repositories, including private forks used for security work. With v6 defaults, 
those workflows would depend on proprietary, mutable terms whose future private 
repository terms and limits are not yet defined. Switching v6 to basic caching 
avoids the proprietary component, but gives up caching behavior that the 
workflow currently relies on.
   
   Revert to v5 so the workflow avoids v6's proprietary enhanced caching 
provider without regressing to the reduced basic caching provider while we 
decide on a longer-term approach.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to