-
Notifications
You must be signed in to change notification settings - Fork 198
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
Comments
This happens to me as well. I have no key defined in Gradle script since I have a file named
Yet bintrayUpload simply succeeds without any output. The following lines are present when Gradle debug is activated:
I'm using Gradle 3.4, maybe it's related? |
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 |
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 :) |
Thank you, that was very helpful! By forcibly loading the local.properties and setting bintray |
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. |
stuck on this yesterday! Wasted half of day to figure out why bintrayUpload task is skipped. I used this approach but the variable name was Thanks for concern. |
is it possible in github issues to vote for the issue? |
I agree - silent skipping is a horrible anti-pattern. I wonder why bintray is silent for almost 2 months about this seemingly simple issue. |
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 |
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. |
@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 i could also contribute a PR if you and other developers above agree on this point |
@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. |
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. |
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
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. |
Note that #206 will probably cause more users to encounter this in the next release. |
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:
When running "bintrayUpload" task:
The text was updated successfully, but these errors were encountered: