When bintray.key is null the bintrayUpload task silently fails

[mockitoguy]

Thank you for Bintray and the plugin!!!

I noticed this bug today. When bintray.key is null the bintrayUpload task silently fails (or seemingly succeeds). For given sample project:

apply plugin: 'java'
apply plugin: 'maven-publish'

dependencies {
    testCompile 'junit:junit:4.12'
}

project.publishing {
    publications {
        DefaultPublication(MavenPublication) {
            from components.java
        }
    }
}

project.apply plugin: "com.jfrog.bintray"

bintray {
    user = 'szczepiq'
    key = null //'secret' //System.env.MOCKITO_BINTRAY_API_KEY

    publications = project.publishing.publications*.name

    publish = true

    pkg {
        repo = 'mockito-release-tools-example-repo'
        userOrg = 'mockito'
        name = 'mockito-release-tools-example'
        desc = project.description
        websiteUrl = 'http://mockito.org'
        issueTrackerUrl = 'https://github.com/mockito/mockito-release-tools/issues'
        vcsUrl = 'https://github.com/mockito/mockito-release-tools.git'
        licenses = ['MIT']
        labels = ['continuous delivery', 'release automation', 'mockito']
        publicDownloadNumbers = true

        // optional version attributes
        version {
            vcsTag = "v$project.version"
            gpg {
                sign = true
            }
        }
    }
}

When running "bintrayUpload" task:

• expected result: authentication / validation failure because 'key' is null
• current result: silent failure (build succeeds but the publication is not done), Gradle output below

~/mockito/example-release$ ./gradlew bintrayUpload
:api:generatePomFileForDefaultPublicationPublication
:api:compileJava UP-TO-DATE
:api:processResources NO-SOURCE
:api:classes UP-TO-DATE
:api:jar UP-TO-DATE
:api:publishDefaultPublicationPublicationToMavenLocal
:api:bintrayUpload

BUILD SUCCESSFUL

[mvysny]

This happens to me as well. I have no key defined in Gradle script since I have a file named local.properties like this:

bintray.user=my username
bintray.apikey=hexa hexa hexa

Yet bintrayUpload simply succeeds without any output. The following lines are present when Gradle debug is activated:

17:37:21.745 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':vok-framework:bintrayUpload'.
17:37:21.745 [INFO] [org.gradle.api.Task] Gradle Bintray Plugin version: 1.7.3
17:37:21.745 [INFO] [org.gradle.api.Task] Skipping task vok-framework
17:37:21.745 [DEBUG] [org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter] Removed task artifact state for {} from context.
17:37:21.745 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':vok-framework:bintrayUpload'

I'm using Gradle 3.4, maybe it's related?

[mockitoguy]

It's this code that has the silent skipping: https://github.com/bintray/gradle-bintray-plugin/blob/master/src/main/groovy/com/jfrog/bintray/gradle/BintrayUploadTask.groovy#L177

[mockitoguy]

There is one more problem related to the silent skipping issue. According to the source code, the 'user' is an '@Optional' field. However, it is required for authentication, so it is not really optional :)

[mvysny]

Thank you, that was very helpful! By forcibly loading the local.properties and setting bintray user and key from those I was finally able to deploy my artifacts.

[mvysny]

Even though I got it working, this way of silently doing nothing is totally inappropriate. It should fail cleanly and eagerly and it should clearly state that the user and key parameters are missing. If there is any reason to skip this plugin, just add a skipDeploy Boolean parameter or something in this regard.

[andrii-kovalenko-ct]

stuck on this yesterday! Wasted half of day to figure out why bintrayUpload task is skipped.

I used this approach key = project.hasProperty('bintrayApiKey') ? project.property('bintrayApiKey') : System.getenv('BINTRAY_API_KEY')

but the variable name was $BINTRAY_API_KEY. It was just a typo, hard to avoid such a things, but at least the plugin should notify me when something is wrong instead of silently skipping the task! IMHO the entire task/build should fail if intended job (e.g., upload) is not done.

Thanks for concern.

[andrii-kovalenko-ct]

is it possible in github issues to vote for the issue?

[mvysny]

I agree - silent skipping is a horrible anti-pattern. I wonder why bintray is silent for almost 2 months about this seemingly simple issue.

[mockitoguy]

I suspect that JFrog folks are waiting for community to pick up the work and contribute :)

I'm working on a continuous delivery toolkit that wraps neatly the Bintray plugin and fixes that particular issue. Check it out: https://github.com/mockito/mockito-release-tools#imagine

[eyalbe4]

I've just merged @artem-zinnatullin 's pull request, for improving the log message when the user or API key are null. Thank you for this @artem-zinnatullin. Any other recommendations and contributions are more than welcome.

[andrii-kovalenko-ct]

@eyalbe4, cool. Though still doesn't look as expected behavior: if nothing could be uploaded because of missing credentials, the task/build should fail. This is important for automation builds: the credentials could be missing (e.g. accidentally removed/re-factored/renamed/bad migration), but the build still will be accounted as SUCCESS (green) instead of FAILED (red)

i could also contribute a PR if you and other developers above agree on this point

[artem-zinnatullin]

@andrii-kovalenko-ct yeah, failing should be default behavior but that will be breaking change, good option could be introducing new task and deprecating old one or if maintainers would like to change default behavior in new major release we could start with warning in current version that would say that behavior is soon to be changed.

[shawnmaten]

Just want to add that I ran into this same issue today using version 1.7.3. I had misspelled an environment variable and was totally lost as to why nothing was getting uploaded.

[bsamartins]

Hi

Saw that there was a Pull request for this issue but the reason it had not been merged was due to issue #74 and concern that it could bring back that issue. What about adding a flag something like this

if(failOnMissingCredentials && shouldSkip()) {
    throw new GradleException("Missing user or apiKey")
} else if (shouldSkip()) {
    logger.info("Skipping task '{}:bintrayUpload' because user or apiKey is null.", this.project.name);
    return
}

I agree with the @mockitoguy that a fail fast solution would be a better solution. You'd have to add a flag to silently ignore missing credentials and thus avoiding the issue raised by #74.

[alicederyn]

Note that https://github.com/bintray/gradle-bintray-plugin/pull/206 will probably cause more users to encounter this in the next release.