Catch that Millionth Download with Bintray’s New Statistics API

Want to know exactly how many times your packages have been downloaded? Bintray has always given you download statistics through its UI, but now you can also get them for professional repositories via REST API. Detailed statistics on downloads per version over any time frame give you deep insights into how your software releases are consumed.
If you have never used statistics in Bintray, go ahead and check it out in the user guide.

Let’s see an example
Say I want to get the daily number of downloads of ‘myCoolPackage’ from October 1st to October 8th, 2015. This is what the stats look like in the Bintray UI:

myCoolPackage Downloads UI Stats Per Week

According to the chart, ‘myCoolPackage’ was downloaded a total of 147,752 times in that period. We can clearly see that there were downloads every day; there were dips on October 4th (Sunday) and October 8th (the chart was generated on October 8th around midday), and the most popular versions were 1.1.0 and 1.2.0.

Now you can get all this information programmatically using the new REST API. Here’s the “daily downloads” API as it is described in the REST API documentation:

GET /packages/:subject/:repo/:package/stats/time_range_downloads

To get the statistics displayed in the chart above, I would use the following command:

curl -X GET "https://api.bintray.com/packages/tamarUser/Maven/myCoolPackage/stats/time_range_downloads" -u tamarUser:***my-top-secret-api-key*** -H "content-type:application/json" -d “{\"from\":\"2015-10-01T12:08:56.235z\",\"to\":\"2015-10-08T12:08:56.235z\"}"

I get the following response in JSON format:

{
  "from":"2015-10-01T00:00:00.000Z",
  "to":"2015-10-08T23:59:59.999Z",
  "records":[
      {"date":"2015-10-01","downloads":
        [{"version":"1.0.5","count":1939},
         {"version":"1.1.0","count":6950},
         {"version":"1.1.3","count":293},
         {"version":"1.1.7","count":116},
         {"version":"1.2.0","count":10111},
         {"version":"1.2.1","count":1329},
         {"version":"1.2.2","count":1706}]},
      {"date":"2015-10-02","downloads":
        [{"version":"1.0.5","count":315},
         {"version":"1.1.0","count":6975},
         {"version":"1.1.3","count":198},
         {"version":"1.1.7","count":121},
         {"version":"1.2.0","count":9967},
         {"version":"1.2.1","count":1290},
         {"version":"1.2.2","count":1759}]},
      {"date":"2015-10-03","downloads":
      ...]
}

The response provides all of the same data that Bintray uses to create the chart in the UI. For each day within the requested date range in which downloads occurred, it lists the number of downloads per version. As simple JSON output, you can easily parse the response and use it any way that helps you analyze your package downloads quickly and effectively. You are now able to identify trends in downloads, your popular versions and more.

Other statistics REST APIs include: total downloads and downloads by country. Keep an eye on this blog to hear about new APIs when we add them.

Good luck!

Is Docker Hub really the best way to distribute your images?

Docker is definitely one of the biggest things to hit the software industry in the last few years. Everyone is using Docker, and Docker Hub is growing rapidly serving over 45,000 images by now. But did you ever ask yourself if Docker Hub is really the best platform to distribute your Docker images. It stands to reason, but reason be damned; We think Bintray has an edge over Docker Hub and here are the reasons why.

1. Fine-grained access control

Yes, Docker Hub recognizes organizations and teams. You can have all the relevant people open an account on Docker Hub and then organize them in whatever way serves your needs to expose or hide registries as you see fit.

But then you want to send your #1 strategic client an early release

How does Docker Hub handle that? Well, you can ask for your customer’s account, and then include him in the right organization or team. But then, you need to be really careful with what you put in the repository you have exposed to him. Or you need to add him to a team, and later remove him. Manageable so far… But now he also wants his boss to see it, and later the CTO, and two weeks later, you find that your guy has just changed jobs and is working for your competitor. Did you remember to remove him from that team or can he still access your private repository?

Bintray removes this pain-point with entitlements and download keys

Bintray lets you create entitlements which define, in minute detail, exactly what part of a repository can be accessed – from a whole repository down to the level of a single path within a repository. You can define who has access by name, geographic region, IP domain and pretty much anything else. You can also limit that access to a very specific period of time. Once you have defined your entitlements, you can then create keys which unlock the access the entitlements provide. Your user needs to provide the key and its associated password each time he accesses a resource which he is entitled to. You can even define what kind of access each entitlement provides. It can be for download only, or for download, upload and delete.

2. Image and Version Level Stats and Logs

Ever wondered how many times your image has been downloaded? Of course you have; it’s a measure of success. But going beyond self-flattery, it’s not enough to know that magic number of downloads. Wouldn’t it be helpful to be able to know who downloaded your images and from where? Bintray gives you that. The stats pages on Bintray give you total numbers, but download logs let you segment the downloads by region, country, IP address, and even down to the specific user and organization. For your public repositories this can be really useful, but for your private repositories it’s critical for you to know who is accessing your packages and what they are doing in your repositories. You can read more about stats and logs in this post the Bintray Blog.

3. There is more to the world than Docker

allforone4Docker may be the best container to have ever hit the software docks, but at the end of the day, you are only using Docker to create a virtual world in which to run your products. And your products are built with packages that are Java, Ruby, NuGet, Python, Debian … and new formats hit the news all the time. How are you going to distribute those? Not on Docker Hub. So should you use Docker Hub for Docker and something else for all the rest? Well, if you can use that something else, aka Bintray, for Docker images too, then why not simplify your life (and scripts) and distribute all packages through Bintray.

All for one and one download center for all.

3.5. For Bintray, distribution is a core competency

Docker is making huge waves in container technology. This is their core competency; not software distribution. You can use Docker Hub to distribute your images, but you must ask yourself, “Will Docker Hub receive the same level of attention from its makers as container technology does?” Bintray’s scalable infrastructure is deployed on clustered servers in multiple data centers around the world, and currently serves over 200 million downloads per month of 200 thousand packages that reside in 50 thousand repositories.

That’s what we call a core competency!

Like Docker Hub, Bintray offers a host of great features like fast CDN downloads, a rich REST API for automation, searchable metadata and more. But like Docker is redefining container technology, Bintray is redefining software distribution. The service tiers offered by Bintray make it the best choice for distribution of both free OSS images as well as for commercial organizations that need enterprise grade software distribution features. Bintray lives and breathes software distribution; that’s what it does, and that’s where it will continue to evolve to stay the best solution for a download center, for Docker images and indeed for all other software package formats.  

Sign me up!

Bintray Premium gives you cool new features such as private repositories, permission management, more storage and so much more. One of the biggest benefits of using a Premium account is the ability to create expirable, signed URLs for your repositories’ content.

Signed URLs you said? What’s that?

A signed URL is an obscure URL with a (potentially) limited lifetime. When your artifacts are published in a private repository, each artifact is hidden from unauthorized Bintray users. If you want to allow any Bintray user, or even or a non-Bintray user to download your package, you can generate a one-time unique URL with an option to limit its validity so that is expires after a certain amount of time. You can also revoke any outstanding URLs at any time.

How does it work?

When you become a premium user in Bintray, your account holds unique, internal, private and public keys. The URL you decide to sign, will be encrypted and decrypted with those keys.

Let’s say user “srubin” has a private repository called “artifactory”.

This private repo contains a file, “artifactory.rar”, that protected from public access. Only authorized users can download it using the standard download link, which is:
https://dl.bintray.com/srubin/artifactory/com/jfrog/artifactorypro/artifactory.rar

Bintray Premium Link Signing

Bintray Premium Link Signing


To allow a one-off download of this file we will generate a signed URL for it using a simple REST call:

curl -XPOST -usrubin:APIKEY "https://api.bintray.com/signed_url/srubin/artifactory/com/jfrog/artifactorypro/artifactory.rar"

Response:

{
"url":"http://dl.bintray.com/srubin/artifactory/com/jfrog/artiafctorypro/artifactory.rar?expiry=1415101346415&signature=BfRaL2HDbCDsPyPThAnlI%2B0TG26NcH4i0ugyKZ%2FjevLiNfEdHXyUh0Q1NNGc1Pz7V1nZkeh9RAafrUyUE%2FMOFQ%3D%3D"
}

By default, this URL will be valid for 24 hours, but we can change that by specifying an expiry time in a simple JSON configuration document:

curl -XPOST -usrubin:APIKEY  -H "Content-Type: application/json"  -d "{\"expiry\":7956915742000}" https://api.bintray.com/signed_url/srubin/artifactory/com/jfrog/artiactorypro/artifactory.rar"

Response:

{
"url":"http://dl.bintray.com/srubin/artifactory/com/jfrog/artiactorypro/artifactory.rar?expiry=7956915742000&signature=g5OC3RXkFhnnFYfsgqFXw9J%2FfmwCzeIsd%2FHCRgm5VjCAhrzij1GPuAv0JwZPhGD0mEqs1y2WcQ77LMrDzp9%3D%3D"
}

More details about this API can be found in our documentation.

Summary

Signed, expirable URLs is a cool new feature of Bintray. It allows you to automate the generation of one-off download URLs and distribute them to any end user.

We will soon extend this feature to make it even cooler. Keep following to see what we have in store for you!

Announcing the Gradle REST Plugin

Hosted and used by Bintray!

Committed, but not pushed

Update:
This plugin has seen some improvements since I posted this.

I’ve recently implemented a new, very simple but very useful Gradle plugin.

the –

GRADLE REST PLUGIN

TA DA!!!

Gradle is the build tool of the future, man, and that’s no secret; I build with Gradle when I possibly can.

I faced a situation where I wanted to invoke a few web-hooks during and after my build; the web-hooks I addressed and the information I sent varied according to the state of my build.
At first I thought I should invoke the web-hooks via independent build steps of my CI server, but that also meant:

  1. Breaking the build to a number of separate Gradle processes instead of single process that will execute all the tasks.
  2. Maintaining the web-hook invocation procedures outside of my standard build descriptors.

The downside of #2 being the fact that should I want to…

View original post 217 more words