Set up GitHub actions to automatically create releases suitable for consumption by the WowUp app
caniko opened this issue ยท 7 comments
WowUp uses releases to update straight from repositories, can you make the latest tags releases also? Similar to Auctionator
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
andRarity_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:
- Dependencies are embedded in the
Libs
folder, according to the specifications in the.pkgmeta
file - Localization phrases are substituted in the TOC and
Locales.lua
file (as expected) - 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.
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 :/
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 ๐ฉ
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:
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!
Uh, sure. I'll need to look into how to set up GitHub actions to automate this, presumably.