Rarity

Rarity

17M Downloads

Set up GitHub actions to automatically create releases suitable for consumption by the WowUp app

caniko opened this issue ยท 7 comments

commented

WowUp uses releases to update straight from repositories, can you make the latest tags releases also? Similar to Auctionator

commented

First step: Let's see what are the transformations that the CF packager applies before publishing a release (this might help determine the complexity of the task at hand). Checking against HEAD via git diff reveals the following changes:

  • It creates two separate addons, Rarity and Rarity_Options, by moving the options module to the root directory (this is trival to automate)
  • It seems to change the line endings (annoying, but ultimately irrelevant)
  • No actual changes to the options module were made
  • Removes ignored files (.github folder, .pkgmeta, .luacheckrc, .lua-format, autoformat.sh, .Changes.lua, README.MD)
  • The formatting is different, presumably due to the latest release not using the autoformatter (irrelevant)
  • It's missing some changes that haven't yet been released (should likely be automated, but irrelevant to this issue)

All of this is whatever, but there are some things we do need to account for:

  1. Dependencies are embedded in the Libs folder, according to the specifications in the .pkgmeta file
  2. Localization phrases are substituted in the TOC and Locales.lua file (as expected)
  3. The changelog is apparently published on their site, which doesn't really affect the release assets (?)

The libraries are located on WowAce's SVN servers, which means we could likely fetch them. Not sure if we need to do anything to get the right version (we simply use the latest version), or packaging steps are involved to make them usable... There's also a "tools used" section which links Rarity with LibDataBroker and AddonLoader, but it seems like they're mostly for reference and not part of the actual release.

Localization is the anticipated problem, which may be solved by the BigWigs packager or not (still TBD).

Changelogs would be another concern; clearly, WowUp supports displaying markdown but I'm not certain how it will determine what files to use. Perhaps it simply takes the GitHub release notes? If so we can automate using the CHANGES.MD file easily enough.

commented

Bumping up the priority here since it seems WowUp won't be able to access CurseForge-hosted addons, and WowUp is the preferred addon manager currently due to its open-source/community-focused nature.

The main issue remains finding a way to do whatever the CurseForge packager is doing, particularly inserting the localization phrases and other special tags. IIRC they had an API to query localization phrases, but I'm unsure if it can fully replace that. There's also https://github.com/BigWigsMods/packager, which might provide a solution (or at least part of it).

I'd also be worried about breaking the builds with (currently) no way of detecting this, but then that's the status quo anyway due to general lack of tests/QA, so I guess it shouldn't be considered a blocking concern :/

commented

Taking a look at the BigWigs packager script next, with the goal of determining whether it meets all the requirements:

  • Can set up a GitHub Actions workflow to deploy to multiple platforms (example here)
  • Can install external dependencies (with a potential issue, see below)
  • Can substitute localization phrases and the project version (that's all the special tags we use)
  • Can use the auto-generated CHANGES.MD file as a changelog to override the default (simple git commit summary, which is bad)

TBD:

  • Do any of the dependencies we embed even use localization phrases? If so, the packager might be unable to deal with it and we have to find a workaround ๐Ÿ˜ฉ
commented

Of all the dependencies included, only LibBabble-SubZone-3.0 seems to even include localization phrases. However, it looks like they don't use any tags that could mess up a release on our end, even if the packager can't resolve them:

image

I also checked the other dependencies (via grep -R @) and while some seem to be using @debug none embed localization phrases we'd have to worry about. That probably means we could use the packager to replace the WebHooks-based release process currently used to deploy to CurseForge without anything breaking... hopefully!

commented

Seems to be working:

image

I'll merge this change and publish a new release shortly; please let me know if something went wrong and I missed it :)

commented

Uh, sure. I'll need to look into how to set up GitHub actions to automate this, presumably.

commented

Looking into this, it appears we need to find a way to create releases without using the CurseForge packager or WowAce localization system. That seems like a lot of work, but might be possible using their localization API and packaging manually?