3f / ghrmeter.user.js

📊📈 Displays statistics for attachments on GitHub Releases page

	More ...

*update every hour

[ ☕ ]

ghrmeter.user.js's Issues

Possible problems when tags contains an unevaluated `$(appveyor_build_version)`

Noticed from incorrect deploying from appveyor in other Jt project:

Uploading artifacts...
[1/1] dist.zip/Jt-_-1.0.0+5f2367c268.zip (17653 bytes)...100%
Deploying artifacts using GitHub provider
Creating "CI-$(appveyor_build_version)" release for repository "3F/Jt" tag "CI-$(appveyor_build_version)" commit 
"5f2367c2681c69530af35695125f214c756d89fb"...
OK

Here's upload https://github.com/3F/Jt/releases/tag/CI-%24(appveyor_build_version)

It does not affect for items at all. Thus, we need to check this for special symbols later

Request mode is "same-origin" but the URL's origin is not same as the request origin

Thanks for releasing that userscript, looks great! I can't get it to work though.

Console error:

Fetch API cannot load https://api.github.com/repos/Jaid/array-to-object-keys/releases.
Request mode is "same-origin" but the URL's origin is not same as the request origin https://github.com.

Screenshot of the exception break in Developer Tools:

Screenshot of the security settings in my userscript manager:

Environment:

Linux 4.15.0-44-generic
Linux Mint 19.1 Cinnamon
Google Chrome 72.0.3626.96 (Official Build) (64-bit)
Tampermonkey 4.7.63

Am I doing something wrong?

Not working on Waterfox with Violentmonkey

There are no counter values with Waterfox.

Efficient alternative to `?after=<tag_name>`. Pagination

While web version uses ?after=<tag_name>, API v3 seems allows only per_page / page requests.
Thus we can't just use {location.search} as it was presented in data.

Alternatively we can of course request to each separate tag/release, BUT!
In fact this means toooo many requests to API:
(unauthenticated: 60 requests per hour / authenticated: 5000 requests per hour)

TODO: Efficient alternative to ?after=<tag_name>.
Current implementation will use only single request via pagination to the first 100 records.
Others requires at least N requests to N page when no related info from web version, eg.:
(100 records page1) -> failed -> (100 records page2) -> failed -> (100 records page3) -> success;

Any after param such /releases?after=v1.6.1 will indicate to the page != 1
But web version uses 10 records per page. That will not help us detect page 11 for the next 100 records.
Anyway, the other records can be processed through individual /releases/tags/:tag