Potential Features

[neil-morrison44]

Hey, just going to sketch out a couple of ideas of what we could do here, roughly in order from "we probably should do it" through to "Hmmm, that's a grey area":

• Using something as the version flag

  • someone suggested githash (guess it'd need to be the latest one that any of the files for the core were updated with which, I guess, could feed into a "does it need to rebuild" thing if needed)
  • definitely needed for Pocket Sync to be able to update, not sure about yours

• "Better" platform JSON files, with the full names, original manufacturer, year etc

  • Would feel a bit awkward changing these since the cores wouldn't be named jt* by default in the list -- the author tag etc wouldn't change though
  • Also would need to maintain a list of "better" platform JSON files (probably in this repo?)
  • Could discuss with JOTEGO, potential compromise changing the category name or something
  • Trademark issues? Doubt it'd matter much but MiSTer went from PS1 -> PSX for something similar I think

• "Better" platform.bin images

  • this one gets into the whole copyrighted imagery grey area, some cores are releasing with them and it'd probably be fine but 🤷🏻‍♂️
  • Also another removal of JT (though, some of the cores don't have images at all just now)
  • Would also need to actually put together & maintain the images somewhere

[mattpannella]

1. i mostly set this up as test to see what i can get going (and to quickly get the jt cores downloading, so i wouldnt have to answer 500x why they dont work) haha but right now i'm grabbing the date_released out of each core's core.json file (he's not putting versions in there) and then appending that to each zip file name. this is how pram0d's release zips are set up as well, so i figured i'd just match that, even if its temporary, this way i could just have support for them in my updater. so that date_released works as a way to version them. i'm just manually maintaining a json file with them in it that i pull from as a second api endpoint with these if you wanna pull that for now til we get something more formalized. https://raw.githubusercontent.com/mattpannella/pocket-updater-utility/main/pocket_updater_cores.json the git hash could work as a version flag too i guess, but i think the dates for each core is a little nicer.

2 & 3. You're definitely right about this one. even though i kinda don't like the idea of doing anything just zipping up and hosting jotego's stuff as is, most people are gonna wanna update those json files anyway so might as well just automate it for them. maybe we can build 2 copies of each, a untouched one and another with our tweaks to the platform and images?

[neil-morrison44]

Yeah, date's probably fine, but Pocket Sync will need it duplicated into the version field (eventually) for it to show that there's an update (since it compares what the core has locally to what the inventory says is the latest version in the new version param)

The only thing with date is it prevents 2 versions being released in a single day, which doesn't seem to be a problem with MiSTer but I've seen a few hot fixes go out for Pocket things.

& yeah, I also have mixed feelings on adjusting the files beyond what's necessary

We can try and reach out to see about the version field / jsons / get blessing on doing this semi-officially somewhere

[mattpannella]

yeah good point about multiple releases on the same day. jotego's cores straight up have the string "noversion" set as their version, so i guess we could maintain our own semver that we just increment? i dont know, that feels like it could get confusing though

[neil-morrison44]

Semver's just a recommendation in the Pocket docs - I think using the git hash of the most recently updated file going into the zip is probably safest, and we wouldn't have to worry about maintaining it (after a bit of faff involved in writing a script to look it up)

[mattpannella]

yeah now that i think about it again, you're right thats probably the easiest/simplest

[mattpannella]

i think we can use the commits end point on the github api and just pass it each path we wanna check for the latest commit inside of (Assets/{platform}, Cores/{identifier}, etc) to see if any files that would be zipped up into a core's release were changed later than the last commit hash we saved https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-commits-on-a-repository

[neil-morrison44]

Yeah that'd work - risk of running into rate limiting though.

If you pass depth: 0 to the checkout action then it pulls the entire git tree down and you can do some git logs etc locally (might be fine with the default depth too, not sure)

[mattpannella]

i THINK you can pass it a path to a directory, and it will just give you the latest commit hash from any file within that tree. you dont need to hit the api for every individual file not sure though, would have to test and i havent actually done anything yet haha

so basically 4 calls per core. pretty sure the rate limit with a token is 1000/hour

[neil-morrison44]

Been playing with this for the last few days, it's scarily good when it's not outright lying

[mattpannella]

lol ive been playing with that a bunch too, its extremely impressive. i should have thought to try that for this haha

[mattpannella]

ok so if i have this update the core.json of each core and put the hash in as the version and then build each zip named corename_{hash}.zip would that cover what you'd need?

[mattpannella]

https://github.com/mattpannella/jtmirror/tree/testing

[neil-morrison44]

That covers it core wise - the inventory json will need to have the new version param too where it says what the latest core self-reports as the version (but we’ll get that once it’s in the inventory proper) since that’s what Pocket Sync checks the local version against

[mattpannella]

alright I pulled the trigger and merged this into the main branch. so this should be running daily to check the jtbin repo for new commits in each core directory and if it finds a new one, rezips up the entire thing and writes the hash into core.json as the version before naming the zip {core name}_{hash}.zip and deleting the previous one so there's only the latest build of each. since the inventory isn't including these yet I just have a json file I'm hosting on my updater repo that mimics the api response, but for these cores, as a temp solution to get support for them. so I can let my app be the guinea pig (but feel free to pull that json down with pocket sync too obviously) then we could work on adding any extra features here like updating the platform names or whatever