Skip to content

When bintray.key is null the bintrayUpload task silently fails #170

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mockitoguy opened this issue Mar 9, 2017 · 15 comments
Open

When bintray.key is null the bintrayUpload task silently fails #170

mockitoguy opened this issue Mar 9, 2017 · 15 comments

Comments

@mockitoguy
Copy link

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
Copy link

mvysny commented Mar 10, 2017

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
Copy link
Author

@mockitoguy
Copy link
Author

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
Copy link

mvysny commented Apr 11, 2017

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
Copy link

mvysny commented Apr 11, 2017

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
Copy link

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
Copy link

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

@mvysny
Copy link

mvysny commented Apr 28, 2017

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
Copy link
Author

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
Copy link
Contributor

eyalbe4 commented Apr 28, 2017

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
Copy link

andrii-kovalenko-ct commented Apr 28, 2017

@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
Copy link
Contributor

@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.

mstachniuk added a commit to mstachniuk/gradle-bintray-plugin that referenced this issue Jun 6, 2017
mstachniuk added a commit to mstachniuk/gradle-bintray-plugin that referenced this issue Jun 7, 2017
mstachniuk added a commit to mstachniuk/gradle-bintray-plugin that referenced this issue Jun 7, 2017
@shawnmaten
Copy link

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
Copy link

bsamartins commented Jan 30, 2018

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
Copy link

Note that #206 will probably cause more users to encounter this in the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants