Migrate to Github releases

[ExtremeFiretop]

Hey @Martinski4GitHub

Any thoughts on this?

This will allow us to get download stats directly from Github for new installs and existing updates for each release going forwards, without using an external provider like Scarf Gateway in front of GitHub downloads and without extra server/hosting infrastructure like TLC has for Diversion and amtm.

Example release with example download stats found here:
https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/releases/tag/release-count-test

I had also prepared an update for amtm .mod file:
decoderman/amtm@bae074a

[Martinski4GitHub]

Hey @Martinski4GitHub

Any thoughts on this?

This will allow us to get download stats directly from Github for new installs and existing updates for each release going forwards, without using an external provider like Scarf Gateway in front of GitHub downloads and without extra server/hosting infrastructure like TLC has for Diversion and amtm.

Example release with example download stats found here: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/releases/tag/release-count-test

I had also prepared an update for amtm .mod file: decoderman/amtm@bae074a

Interesting approach. I wonder how reliable or representative (of the actual number of users) these counters would be, given that in your notes you stated that this mechanism doesn't distinguish unique users or routers. IOW, it doesn't keep an anonymized record of the caller's IP address, so the counter is incremented even when the very same user does a re-install, a force update, or perhaps manual downloads of the same release version.

I suppose the counters could provide a rough estimate of the user base, although I'm not sure how useful that is, IMO.

In any case, I imagine you're still testing the concept at this point to check the results.

Wishing you good luck, bud!!

[ExtremeFiretop]

Hey @Martinski4GitHub
Any thoughts on this?
This will allow us to get download stats directly from Github for new installs and existing updates for each release going forwards, without using an external provider like Scarf Gateway in front of GitHub downloads and without extra server/hosting infrastructure like TLC has for Diversion and amtm.
Example release with example download stats found here: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/releases/tag/release-count-test
I had also prepared an update for amtm .mod file: decoderman/amtm@bae074a

Interesting approach. I wonder how reliable or representative (of the actual number of users) these counters would be, given that in your notes you stated that this mechanism doesn't distinguish unique users or routers. IOW, it doesn't keep an anonymized record of the caller's IP address, so the counter is incremented even when the very same user does a re-install, a force update, or perhaps manual downloads of the same release version.

To what I can tell from the firmware "release" I did with the nvram bug fix. Very accurate. Delayed, but accurate. I can manually test from that asset I posted, and everytime it takes a few minutes but the download count increases.

And while your correct it's not perfect. The goal is to get numbers without putting gateways in front of the script that could compromise a users feeling of privacy.
As Viktor pointed out here: https://www.snbforums.com/threads/thinking-of-leveraging-scarf-for-download-stats-for-my-addons.76389/post-982383

The conclusion of that thread is basically not everyone likes scarf but there was no general / universal playbook to follow that the community landed on.

As you can tell by the test asset I published, the stats are basic, rudimentary numbers. They don't give me IPs. They don't give me location, they don't give me anything else other than "downloaded x times"

Yes the numbers could get fuzzy with multiple reinstalls or forced updates, but let's be honest that isn't much, I doubt it would influence numbers much.

Actually when we start seeing a pattern, if one release has many new installs for example, it could mean a very popular release that got lots of new users, or lots of existing users with issues that had to reinstall from scratch. At least it's data.

I suppose the counters could provide a rough estimate of the user base, although I'm not sure how useful that is, IMO.

Exactly. The goal is not to get perfect exact numbers. The goal is to see any patterns over time. When I noticed I could see download counts on the release I did for that nvram bug:

Release GT-BE98_PRO_9.0.0.6_102_42015-g73e87ed_1592-g6178c_BB0B_nand_squashfs.pkgtb · ExtremeFiretop/wlscm-debug-reproducer

My brain started turning... What if instead of downloading MerlinAU directly using the raw GitHub URL. I publish the source code as a release, and make the scripts download the published release.

Then I'll get download counts per release...

Then I thought... If I split the URLs between new installs and updates. I would be able to say "version 1.7.0 had approximately x new installs, and x number of updates" and see the progression with each new release.

In any case, I imagine you're still testing the concept at this point to check the results.

Wishing you good luck, bud!!

Yeah I'm still testing, I just wanted to get your opinion on this solution before spending more time on it.

So far I really tested the workflow more than anything.
I tested that the release workflow logic generates the 2 expected files.

And that a real GitHub prerelease was created successfully and confirmed that GitHub keeps independent download counters for the two assets.

And the two assets correctly contained:

readonly RELEASE_ASSET_KIND="install"
And
readonly RELEASE_ASSET_KIND="update"

Things I haven't tested yet but plan too are:

Router runtime testing of the actual self-update path...
AMTM fresh installs with the .mod file...
Intended fallback behavior...

[ExtremeFiretop]

@Martinski4GitHub

This is good to go :)
I tested the workflows, and the script code, I added a quick test function and validated the flow correctly grabbed the right update file.

If you need me to recreate the test assets for you to test, let me know!
Otherwise all is good on my side now after those 2 quick fixes.

[ExtremeFiretop]

And Viktor also implemented something similar for his brand new IOCMON:
https://www.snbforums.com/threads/release-iocmon-v1-0-0-2026-oct-03-asus-merlin-security-intelligence-monitor.97925/post-1006761

I gave him the idea, but the better metrics through the .py script is his implementation he tossed back our way in return ;)