.toc is a little bit of a weird one, because 70300 could mean 7.3 like it could mean 7.3.2 or 7.3.5, so it's probably not as simple as just reading from .toc.
Unless they finally started adding minor revision number to interface version number, at least, but I imagine they have reasons for why they haven't done that. |
Quote:
Modify your ".travis.yaml", changing the line that says "script" into this: Code:
script: curl -sO https://raw.githubusercontent.com/BigWigsMods/packager/master/release.sh Quote:
https://api.wowinterface.com/addons/compatible.json |
Quote:
Thank you again ^^ |
Thank you for this guide!
I already had a .pkgmeta for the CurseForge packer so setting this up for my addon was quite easy and I got my first automated release to WoWI :) I am a bit confused about the release to GitHub. I used the "Draft a Release" feature on the side but that does not work with the packer since that already creates a release on the site? Code:
Uploading ChocolateBar-v3.1.2.zip (7.3.0) to https://www.wowinterface.com/downloads/info12326 Code:
git tag v3.1.3 && push --tags Two side notes: As you mentioned I had to adjust the regular expression in the .travis.yml to work with my version scheme. It has a leading "v". Since this version scheme is quite common you could include an info how to adjust regex for that scheme in the guide. I noticed that the CurseForge link to the keywords substitutions has changed. |
Quote:
|
Quote:
If that doesn't happen, report it on the packager repo. Quote:
Quote:
|
Quote:
Regarding the Curse version stuff, their new versions endpoint is lacking and they don't seem keen on improving it. The old platform included "in_development" and "internal_id" (toc) so it was pretty easy to pick the current version. Now the only context you get is the version name, so when the version isn't set manually all I can do is grab the latest one, which obviously doesn't work so well when there is a new version in testing. :mad: As a stopgap I committed using 7.3.5 as the default version for Curse uploads, but I really am hoping the endpoint gets better. The WoWI versions json, on the other hand, is much nicer and has a "default" flag :p (Although it would be nice if they added new patch versions) |
Quote:
|
Quote:
|
Thank you for the excellent guide! You have tremendously simplified my workflow and made it much easier to push out new releases!
My question is related to the pkgmeta file. I'm relatively new to the addon writing world, and I'm trying to understand the difference between externals, dependencies, and tools. Could you point me to a good guide on when to use each? The Curse documentation is sorely lacking beyond the bare how-to; it assumes you already know what the difference is. Besides, the automated method bypasses the Curse packager anyway. As an example, I've been using LibStub, CallbackHandler, and LibDataBroker in my addons, and until now, I've simply placed those files in my repository and included them in my .toc file. I tried to include them as externals, but I ended up with a massive amount of files I didn't need in my addon zip file, like test cases and documentation. I'm now moving towards the Ace3 framework, so I thought to include Ace3 and the other libraries I'm using in my externals list - but I got with something like three copies of libstub and callbackhandler, including in directories under the Ace3 hierarchy! I played around with it a bit, but eventually gave up and went back to just including the files I want in my repo. Any advice would be appreciated. |
Quote:
Optional-/required-dependencies is metadata Curse uses for their client (afaik). Tools-used I think is just something you'd put in so that tool would get some points for the rewards program (again, CF stuff). In your example with the three libraries: Code:
externals: Another field in .pkgmeta is the "ignore" list. Sadly, not enough libraries use this field, such as LibStub, so you'll end up with useless files like you mentioned. The packager will recursively check for the ignore list in the externals' .pkgmeta file, but it won't recursively get their externals (if any). You can however add externals' files you want to ignore for the packaging, as it's the last thing it does. As for Ace3, check out Phanx's addons (specifically Grid), she's using a bucketload of Ace3 modules in that addon, and uses this packager as well. While looking at it, notice how she's managed to get all of the libraries from externals alone, you only see them referenced in .pkgmeta and Grid.toc. |
Thanks again for the awesome advice, I'll check it out!
|
Quote:
Proof of concept: Create a new project with the following .pkgmeta. Package it using release.sh. You'll see the tests subdir under Libs/LibStub is packaged. Code:
ignore: |
I coded up the changes necessary to have the ignore directive apply to externals, and submitted it as a pull request to the main packager repository:
https://github.com/BigWigsMods/packager/pull/17 |
Code:
install: echo -e "[alias]\nclone = clone --insecure" > ~/.hgrc |
I'm a bit curious about this. I checked Travis-CI and it doesn't seem to have any native support for Lua. I'm assuming that without some additional scripts, it doesn't actually validate the code, but rather just packages it, yeah?
|
Quote:
|
Quote:
|
Quote:
Quote:
|
Quote:
Everything else is detected from the .travis.yml file. Edit: I've updated the guide to reflect the changes from travis-ci.org to travis-ci.com. (Although personally I've moved over to CircleCI instead, see packager#18 if you're interested) |
All times are GMT -6. The time now is 08:16 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI