@tzanio @v-dobrev: Just FYI, I've seen LLNL block bit.ly. Have you seen this?

Also while we're on the topic -- do you guys only need download counts or do you want the referer data for these downloads as well? If you only want download counts, you can get that through GitHub's API. For MFEM, it would show up here:

https://api.github.com/repos/mfem/mfem/releases

You can't see a download count right now b/c you're linking people to the /archive/<tarball> URLs that GitHub associates with any tag, but if you upload a specific release tarball with your releases, it'll actually track the downloads.

Would that get you guys away from the weird URLs?

Here's an example for Spack with a tarball asset attached: https://api.github.com/repos/spack/spack/releases

You can see that the 0.11.2 tarball was downloaded 130+ times. I guess it also shows that everyone uses Spack on the develop branch, b/c we get 400-500 clones/day.

@tgamblin wrote in #8453 (comment)

@tzanio @v-dobrev: Just FYI, I've seen LLNL block bit.ly. Have you seen this?

No I have not seen this. Where can I reproduce, e.g. with https://bit.ly/mfem-3-4?

@tgamblin, it looks like bitly is not blocked from LLNL, at least as of now.

Regarding using the GitHub "analytics": we looked at that at some point but they were not as nice as the analytics from the google shortener. I have not looked at the bitly analytics specifically but I assume they are similar to google's.

Are these short links causing any issues/headaches in Spack?

@tzanio, @v-dobrev: no, I don't particularly care about the fancy links, since we've added functionality to handle them well. Though the extrapolation still doesn't really work on them.

I haven't seen the error recently, I just know that LLNL has blocked bit.ly in the past -- it is usually transient.