Missing credentials should not stop the build, if not being used.

[bpappin]

Describe the bug

When the plugin is enabled, but publishing is not being used, and the keys not present, an exception that fails the build occurs:

* What went wrong:
A problem occurred configuring project ':app'.
> No credentials specified. Please read our docs for more details:
  https://github.com/Triple-T/gradle-play-publisher#authenticating-gradle-play-publisher

...
Caused by: java.lang.IllegalStateException: No credentials specified. Please read our docs for more details:
https://github.com/Triple-T/gradle-play-publisher#authenticating-gradle-play-publisher

How To Reproduce

Simply configure the plugin, but leave out the credentials file and/or environment variable.

Versions

n/a

Tasks executed

Nothing that should execute against the server was run.

Expected behavior

A warning at most. No error stopping the build should be generated, if the tasks that uses the key is not being run.

Additional context (if a crash, provide stack trace)

This is a sanity check on the CI server, trying to run unit tests. It does not need the sensitive publishing keys to be included in the workflow. The plugin should not stop the build, unless it's specifically trying to use the missing key.

[bpappin]

I was able to work around it by adding a fake env variable with just a JSon object in it: ANDROID_PUBLISHER_CREDENTIALS={}

However, I shouldn't have to, and the fact that its empty just shows that the plugin doesn't really care if its there, at that point.

[SUPERCILEX]

Oh yeah, please don't do that. Instead set the enabled property to false in your CI testing environment: https://github.com/Triple-T/gradle-play-publisher#disabling-publishing

[bpappin]

I can try that, but why is it checking at all? I don't want to have to tell everyone else or the CI server, to disable the plugin, or enable it (depending on which way the option is flipped). It becomes cumbersome to coordinate.

[bpappin]

OK, I just tried the enabled = false setup as you described, but it doesn't work, you still get an error without the property .

[SUPERCILEX]

There are no known issues with enabled so I'm guessing you're either not applying it globally or not setting it to the right value. The standard way to do it is like so: play { enabled.set(file('creds.json').exists()) /* ... */ }.

Honestly I don't really remember why we still check to make sure the property is there. Maybe it was for a better onboarding experience? Anyway, I can consider removing the check.

[bpappin]

I am basically doing that. Enable is false for all variants, except the variant that publishes the bundle.

I use the environment variable, so that I can keep the key secure, and out of the git repo. It's also harder to store a key file securely in a ci server where you may not have access to the file system.

Verifying the key is great, but it should only stop the build if it's going to be used.

On Wed., Mar. 17, 2021, 00:58 Alex Saveau, @.***> wrote:

There are no known issues with enabled so I'm guessing you're either not applying it globally or not setting it to the right value. The standard way to do it is like so: play { enabled.set(file('creds.json').exists()) / ... / }.

Honestly I don't really remember why we still check to make sure the property is there. Maybe it was for a better onboarding experience? Anyway, I can consider removing the check.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Triple-T/gradle-play-publisher/issues/925#issuecomment-800794439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5ZCWIDH57RWSICEPZFIWTTEAZHDANCNFSM4ZJGXK4Q .

[mochadwi]

+1 for this

[MiguelLarios]

Experiencing the same issue. Adding enabled.set(false) and still fails because credentials checking

[groff]

I still have this issue on 3.4.0-agp7.0. play { enabled.set(false)} playConfigs {register("variantName") {enabled.set(true)}}

[SUPERCILEX]

Are you using resolutionStategry auto? That will require credentials to build a release version of your app.

If you're able to run ./gradlew help without issue, then this is a seperate problem.

[bpappin]

@SUPERCILEX i can confirm that "./gradlew help" does not trigger the problem.