Extraneous GitHub releases

[layday]

It would seem that you've got a cron job running every 3h in each one of these repos creating a new GH release regardless of whether the underlying version on CF has changed. Seeing as add-on managers will typically interpret the GH tag as the add-on version, this is a lot of churn for their (and your) users.

[srhinos]

Ah, assuming this is an issue with instawow? I mainly used Cursebreaker and WowUp when testing but both will pull the most recent release and version check the release's TOC to see if it's an actual upgrade before marking an upgrade as being available. Unsure if they pull the file regardless of the actual release title being different or not but I'd for sure be open to a PR that fixes this!

For context, I went with this pattern as keeping state of the mirrored Addon would be a giant PITA. I saw I could successfully side step the issue with just frequent releases but I'd ideally love the ability to generate a release when actually needed and push out the change log too with it.

[layday]

Unsure about WowUp, but I don't think CurseBreaker does that, just from the reading the implementation. It will extract the version from release.json if it exists, otherwise it'll use the tag name. An accompanying release.json would work around this issue in CurseBreaker (see here for its schema).

instawow considers add-on archives to be immutable and will download them (usually in part) to check compatibility in the absence of release.json. It's a little sophisticated about this - it'll try to perform a ranged request from the end of the archive with the approximate average size of the central directory, looking for a TOC file with an expansion-specific extension. I suppose I could potentially read the version from the archive too, but that would mean having to download it in full, slowing down updates with a cold cache and using up a lot more bandwidth. Creating new releases with identical archives bypasses the cache.

If you would generate release.jsons, I might do as CurseBreaker does and read the version from there.

[srhinos]

Weird, I don't remember seeing many issues with redownloading releases when I was using CurseBreaker for a bit last year in conjunction with this repo but I may be wrong and just didn't notice.

Creating a release.json would probably be the easiest solve tho I'd have to dig into how to actually do this properly for games that release classic, era, and retail versions of the addon with independent breaking changes between them all.

Lemme know what works best tho, would love to get better support for instawow

[layday]

What would work best is not creating multiple releases for the same version :)

[srhinos]

I guess more "what works best AND doesn't require me to layer on a ton of extra complexity to hold state"?

My goal with the original scripting was to foist all of the work on GitHub Actions and lean on Releases for storage.

Like I said, ideal solution is to not release via from cron jobs but that's a pretty large lift that I don't really want to work on so happy to take contributions to change towards that goal.

If release.jsons are the next best thing, that's a lot easier to achieve and I'd be happy to knock that out but lemme know if that's a big lift on your end to implement.

[layday]

release.json is the next best thing indeed. It's not a big lift on my end.

[layday]

Done from my side in https://github.com/layday/instawow/commit/4019269efe355f9770aedfb285d43837c6bf46f4.

[layday]

I might have to roll this back because version pinning works off git tags.

[Sinaloit]

What about adding the current MD5 hash that is available from curseforge to the body of the release. Then when you check for a new version you can use the latest release API and see if the MD5 is the same or not and only release if different. True MD5 hashes can stay the same but not super likely.

Example Latest Release REST: https://api.github.com/repos/curseforge-mirror/details/releases/latest

[layday]

Well, I'm not too keen on parsing a free-text field to extract the hash. Hashes are per file (SHA1 is also available from the API), so we'd either have to calculate a meta-hash or list them all. And this doesn't solve being able to retrieve a specific release by its version, i.e. by its tag. It has no benefit over the release.json approach, which is cleaner. Thanks for the suggestion, though.

[srhinos]

taking a look at this project as its growing out of date since wrath turned into cata and now seasonal classic exists as a concept. I'll take a crack at rewriting the pipeline at some point before TWW releases and address this issue.

Biggest motivator besides unblocking you @layday is to also get good change logs pulled from Curseforge or where ever to insert into the releases which is currently impossible. Let me know if theres anything else I should keep in mind when rewriting this to make your life easier!

[torkus]

hey man, audacious project. The three-hourly releases are pretty crazy and you're in an ethical grey area so anything you can do to ensure the goodwill of the addon author community will be essential. I see a means to easily opt-out, that's a good first step. Guaranteeing the integrity and correctness of the mirrored releases would be another, which would mean hashes and correct release names, provenance, etc.

It's your project, your rules, so if you think these things are outside of it's scope and you have no intention of addressing them then that's fine too. There's no pressure from me. Good luck.

[srhinos]

hey man, audacious project. The three-hourly releases are pretty crazy and you're in an ethical grey area so anything you can do to ensure the goodwill of the addon author community will be essential.

Haha this project is pretty old now and the bridges were burnt forever ago. Its of no consequence to me what a bunch of people in spaces I don't visit think about me. I publish everything I work on on GitHub and this is just another "thing" and not something I feel a need to monetize, gain notoriety from, nor really even support particularly well.

I see a means to easily opt-out, that's a good first step. Guaranteeing the integrity and correctness of the mirrored releases would be another, which would mean hashes and correct release names, provenance, etc.

Yeah this is the eventual goal but its pending me getting actual motivation to do anything with this project when its currently working just fine for me. Curious though, would just similar-to-BigWigs-packager style releases be good for you and your needs? Its good to have this info so when I do actually feel a need to be productive, I know what I gotta do. Right now, I'm depending on WowUp's first in class ultra advanced decisioning logic:

1. Fetch most recent release
2. Check to see if the installed .zip file name is different than the current .zip file name.
3. Install the new version if it is, even if the encoded version in the .zip file name is lower B)

It's your project, your rules, so if you think these things are outside of it's scope and you have no intention of addressing them then that's fine too. There's no pressure from me. Good luck.

This is a very chill project thats just there for myself to use and having others interested is just a cool by-product. More than happy to take suggestions and action them as I find the time! As with the Instawow suggestions, any suggestions you have to improve compatibility would be very much appreciated!