download_count is missing in the GitHub releases API

[ElfQrin]

I don't know how many times releases for this repository (or any other repository in my account) were downloaded because download_count is missing.

For example, if you open in your browser:
https://api.github.com/repos/ElfQrin/webservertest/releases
and search for "download_count" there isn't any.

But if you check another repository in another account (not mine, for example):
https://api.github.com/repos/clechasseur/pathcopycopy/releases
You'll find an occurrence of "download_count" for every release.

[calebcartwright]

It sounds like your core objective is to gain an understanding of how many users are consuming your tools/packages/software/etc., and that you'd like to be able to have a status badge display that data.

We're a ways outside the realm of Shields.io but here's some info you may (or may not) find helpful:

• If and how download/install/etc. counts are tracked ultimately depends on how you package your software, where it is published, and how your end users consume it.
• I personally know very little about the PHP ecosystem, but one common pattern (which Shields.io provides badges for) is for PHP packages to be published to packagist and then downloaded/consumed via Composer.
  • For example this downloads/month badge for doctrine/orm
• Other packages/binaries/tools are published to & consumed from other places (docker hub, npmjs, maven central, etc.), including some tools whose binaries are published to GitHub in a release, and the way end users consume those tools is by downloading one of those binaries from GitHub
  • The repo you linked as an example (https://github.com/clechasseur/pathcopycopy) is a windows explorer add-on, and when a user wants to consume pathcopycopy, they have to download a binary from a release in that GitHub repo in order to acquire that tool. <-- That is why GitHub has a download_count value for those releases

The first question for you in determining how frequently your software is being used is to determine how users are consuming the content of this repo (webservertest)? Do they clone the repository and run/deploy it? Do they copy the contents of your page script and paste it into their own applications? Etc. Your readme doc doesn't specify how someone would consume it so I just don't know (although perhaps a developer more well-versed in PHP would).

You are creating git tags and GH releases with those tags, but the only way you would ever see a download_count is if a user/consumer of your product were to go to one of your published releases and download one of those binaries:

If that is not how you intend/expect your users to consume your product, then GitHub Release Download count will never be a good metric for you to determine how many users are consuming your product

[ElfQrin]

Hi @calebcartwright , thank you very much for your reply. I agree with you: this is not about PHP or any other language, the counter should start when someone download an asset from a release (.zip or .tar.gz).

That said, it's impossible that nobody, ever, has downloaded any of my releases in any of my repositories. In fact, I've tried to download zip and tar.gz files myself (from another browser, without logging in to GitHub), and still I can't see any counter (download_count).

[calebcartwright]

In fact, I've tried to download zip and tar.gz files myself (from another browser, without logging in to GitHub), and still I can't see any counter (download_count).

Did you create and publish those tarballs/zips as Release assets yourself? Or are those the source code package ones GitHub created for you as part of the tag/release creation process? I'm not sure whether the GH-created source packages count but you'd need to check with GH on that

If you think there's a bug in the GitHub API (FWIW I personally do not), then you'll need to take that up with GitHub. My key point though is that either way, GH release download count is likely not going to be the best place to get a feel for how many people are consuming your content IMO.

Best of luck!