For very odd reasons I have to stick to gradle 2.13 when I need to provide encrypted credentials for the authentication to access a repository. To encrypt the user credentials into a gradle.encrypted.properties, I’ve applied Etienne’s plugin (GitHub - etiennestuder/gradle-credentials-plugin: Gradle plugin to store and access encrypted credentials for use in Gradle builds.). It works, I can retrieve my unencrypted credentials in the build.gradle of my project. The problem I have now is, that there’s another plugin that configures the repositories, and, it awaits either environment variables set with the credentials or system properties.
I tried a lot of ways to pass the credential.username/password using System.properties[‘repoUserName’] = credential.username in init.gradle or in build.gradle. But the repository configuration plugin is not finding/using it.
Can someone give me a kick towards a solution?
Update: 2021/11/18 - from System.property TO System.properties
System.property['xyz'] should be crashing, since System has no such property property. Makes me suspect that maybe the code in question is not being executed. Are you sure it is? If it is, that’s weird that it “works” (it crashes Gradle for me), but have you tried using System.setProperty(k,v) or System.propertis[k] = v?
This configures various repositories from a “corporate distribution” which contains an init.gradle with all of the repository configuration. The init.gradle uses the repoconfig-gradle-plugin and this plugin wants the credentials to be available via a) environment variables or b) java system parameters. So we can’t pass it from credentials.username/password and also not if set via System.properties[‘repoUserName’] = credentials.username. We tried to put it into the root project’s build.gradle but also to enable it in the init.gradle of the corporate distribution. While we tested using “println” that parameters are set into System.properties, the plugin won’t be aware of them.
I guess this is because we set the environment variables to a current shell/jvm instance and they’re not propagated to the one that is used during execution phase. To show this is true we would be debugging the repoconfig-gradle-plugin, I guess. Right?