Allow wrapper to use distribution credential from environment

[avi-sanwal]

Expected Behavior

Option 1:

Expose set ENV variable keys such as -

• GRADLE_WRAPPER_USERNAME
• GRADLE_WRAPPER_PASSWORD

Option 2:

Provide an option of configurable env. keys via gradle-wrapper.properties which is located within projects.
This allows per project configurability, avoiding security issues that can occur due to multiple projects, for example in a developer machine.

Option 3:

Make distribution URL configurable based on env, so that we can provide https://username:password@somehost format.

Current Behavior (optional)

Wrapper expects credentials to be specified in .gradle/gradle.properties or via distributionUrl=https://username:password@somehost format.
This is not convinient in build environments where often ephimeral nodes are used for running gradle.

Context

Due to the current limitations in how the wrapper credentials can be provided, we have not been able to use a custom distribution URL (which is authenticated).

Why current approach has limitations -

1. Our team does not own the build nodes. Furthermore these nodes are shared by different teams. So using .gradle/gradle.properties is not possible.
2. distributionUrl=https://username:password@somehost is not suitable as this would require us to hard code the credentials in project's gradle-wrapper.properties.

Also see:

• Allow wrapper to reuse the existing credential in the system properties #17223
• Allow wrapper credentials to be specified for specific domains #26143
• Allow distributionUrl be set from an environment variable #8477
• https://stackoverflow.com/questions/45310011/how-do-i-provide-credentials-for-gradle-wrapper-without-embedding-them-in-my-pro
• https://discuss.gradle.org/t/configure-gradle-wrapper-distribution-url-based-on-environment-variable-user-property-whatever-else/43246

All of these requests could help you decide on the final approach taken. Mostly I would also like to highlight that these customization are much sought after and cannot be called an obscure ask. Using env. to influence builds is a very common pattern in Jenkins and similar build setups.

[ljacomet]

This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.

[avi-sanwal]

Thank you @ljacomet.