search

bintray / gradle-bintray-plugin

Apache License 2.0
1.28k stars 194 forks source link

avoid creation of a new version if it is binary equal with the latest version #27

Open mockitoguy opened 10 years ago

mockitoguy commented 10 years ago

Hey,

It would be awesome if there was some way to configure bintray plugin to avoid uploading a new version if latest version is binary the same.

My use case is continuous deployment of Mockito. I'm already pushing new minor version for every successful build after every push. However, sometimes I just push some changes to the project that do not incur any changes to the binaries that are published.

Anyhow, I'll implement this myself in Mockito build - just wanted to give heads up that some support for this would very useful :)

Thanks guys for bintray!

yoav commented 10 years ago

This can be done by skipping an upload if the sha1 of the artifact is already the same for the target path. Is your main goal to save the upload time or to avoid the version publication notification?

mockitoguy commented 9 years ago

Hey Yoav, sorry for late answer - for some reason I haven't seen a notification about your reply.

My main use case is avoid releasing a new version if every artifact included in the publishing task is binary equal with previously released ones. It is useful in continuous deployment mode when every push to GitHub releases a new version (Mockito automation is set up this way).

The exact use case is:

  1. I've added a new test case to the code. There are no other changes, no production code changes, etc. The build produces the same binaries as the previous release.
  2. I push the change. I still want my CI (Travis) to run the build but I don't want new version published. Also, I don't want any other automation steps to take place (e.g. no tag creation, no javadoc html publication, etc.)
  3. Currently, Mockito automation will perform a new release in this scenario. The new version will be a bit awkward because it won't have anything in the release notes (they are also automated). It also incurs extra download for the users, and possibly, extra confusion.
  4. My current workaround is to push such changes with [ci skip] in the commit message and this makes Travis CI to avoid running the build. My target workaround is to download the previous release jars, compare them and decide whether to stop the release procedure or continue.
  5. My preferred solution would be a new task contributed by gradle bintray plugin, some kind of 'bintrayUploadNeeded'. The task could produce some file with result or have some query method on the task class API so that I can find out the result after execution of the task. Alternatively, bintrayUpload task could have an option to skip upload when all jars/poms included in upload are equal with the previous release. In that case, the task could also have some getter on its API, so that I can select next steps based on the upload status.

Think about it :) I'd say it would be very useful for continuous deployment!