Auto-update mods option (enabled by github access token)

[SomeTroglodyte]

References

• Closes Feature request: Mod Manager auto update mods added via github that don't have tags #11023
• Closes Auto-update mods option #10903
• Might have helped Mod Management Menu Never Finishes Loading #11017
• See Missing mods in Downloadable mods list #6758
• See Display mod release versions #10900

Notes

• You MUST provide a github "personal access token" for any of this to show. Advanced tab. Looks like ''ghp_" plus 36 base62 chars.
• I fully expected the mod manager to speed up markedly, but got disappointed. The data that goes over the wire is maybe 20% of what it is with the REST api, but that seems to not be the bottleneck.
• The test container was crucial to get this to work, so I left it in. Pollutes the build runner console output with a few more counts of ignored tests.
• Flow is as follows:
  - Start Unciv (or change access token while options is open from main menu).
  - Immediately starts a background query to github asking for limited metadata of just the mods you installed, query and answer have chances to fit in one packet.
  - While this runs there's the old animated loading icon in the bottom left corner of the Mods button - and it's grayed.
  - When the answer comes, is can be a failure or partially successful: Errors are displayed, the prevalent one (you got a mod without public repo) made translatable.
  - The "Ignore" button of the error popup causes that exact same set of errors to be ignored on subsequent starts
  - Timestamps are compared, and if any mod is outdated the Mods button text changes to "Update Mods"
  - Clicking "Update Mods" asks whether you want to update, listing the mods, and a No goes directly to the mod manager
  - "Yes" starts another background job downloading and installing the outdated mods
  - While this runs the Mods button is grayed and disabled - but all others are not and will cancel the job
  - I' convinced browsing Civilopedia while the autoupdater finishes is possible - untested.
• I'm still convinced the idea behind 10900 was right. Mods that don't do releases - unchanged as before, but mods that do - display them and use their timestamps for update checks instead. Playing a post-release per-commit version of a release-using mod requires manual URL entry. Good Idea ™️. All relevant data is already prepared in the GraphQL framework.

Questions

• I got a PAT belonging to a testing account that does nothing else. We could cheat a little and get that into Unciv - except gitshrub recognizes it in source and blocks such pushes. But - it's a "political" decision first. Should we dare?
• ConfirmPopup... My what a long way from YesNoPopup. Almost obsolete - only three uses, wonder why. Could drop and reroute to the "with details" one, and maybe find other potential clients that bypassed ConfirmPopup for similar reasons... Not this PR.
• In that little thing I replaced the use of addGoodSizedLabel - just to distribute wrapped words better - and that only because I test with screen size tiny and a small video clip friendly window. Patch the addGoodSizedLabel method globally instead?

Visuals

An outdated video - too lazy to artificially outdate mods to capture a fresh one
(and the percentage is off due to boxing closures and concurrency - long fixed):

Peek.2024-06-01.Autoupdate.mp4

"wanna update" question:

"hey errors" popup:

[AdityaMH]

"Update All" button inside mods page also better.

image

Great repo that never existed.

[yairm210]

• PAT for testing account - no, will overload. We have ~17K daily active users consistently, on Google Play alone. We get 5000 requests per hour. Even if each request only counts as one, we'll be getting failures.
  
  (for context: that's Daily Active Users for the past half year)

• I don't particularly Github PATs being required for this feature. If there's a convoluted path to being minorly more efficient, I think it actually results in a worse user experience overall

[SomeTroglodyte]

• will overload

Good point, but I'm not sure translating that down to ratelimit points will be enough to overload the ratelimit. Not every player there will open mod manager or relaunch often. And the GraphQL ratelimit is a) much more generous and b) depends on query - count of nodes. This is balanced so any query roundtrip costs one point (ahem, I did those calculations a while ago, hope they still hold), meaning per hour we can cover 5000 autoupdate queries or 625 mod manager launches (assuming 800 mods in existence). So... the overload likelihood is possibly even comparable to the REST ratelimit, hard to say. But then again that's why I stalled this for so long - I simply didn't have the idea to let users enter their own PAT, which makes the ratelimit a thing of the past.

worse user experience overall

Possibly. Then again, took me just under a minute just now, most of that searching "where did they hide that again?". With a nice terse wiki entry¹, we could enable a lot of them - and the ones la... ahem, the rest is simply stuck with REST and manual updates...

Footnotes

1. log in, go to https://github.com/settings/tokens, click generate new token (classic), call it "Unciv mod updates" or whatever, select no expiration, select 4th checkbox "public_repo", scroll down and click green button. Copy the token somewhere safe, like your KeePass. Paste in Unciv Options - github token... ↩

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved.

[yairm210]

This one is still a "no" for me, so long as it uses a Github PAT.
I understand where you're coming from but this is not a direction I want the game to go in.
Would be happy to have an autoupdate that does not use PATs

[SomeTroglodyte]

Would be happy to have an autoupdate that does not use PATs

Would take 15-20s, not 500ms, as you cannot ask the REST api to cough up metadata on a specific preselected list of repositories. I only merged this forward to get us more thinking time.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.