Quantcast Guide: Automagically package and publish addons - Page 2 - WoWInterface
Thread Tools Display Modes
05-08-18, 01:45 AM   #21
Ammako
A Cobalt Mageweaver
 
Ammako's Avatar
AddOn Author - Click to view addons
Join Date: Jun 2016
Posts: 209
.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.
__________________
█████████████
█████████████
█████████████
█████████████

Last edited by Ammako : 05-08-18 at 01:48 AM.
  Reply With Quote
05-08-18, 01:59 AM   #22
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,646
Originally Posted by Ellypse View Post
Do you know if there is a way to provide CurseForge with the supported version? Right now, every build uploaded to CurseForge is flagged for 8.0 and I have to go and manually replace the flag for 7.3.5. It would be really great if there was a way to read the .toc files and use the interface version number to flag the build on CurseForge correctly.
Seems like CF hastily enabled 8.0 as the default. You can force a certain version by passing it through to the packager.
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
after_script: bash release.sh -g 7.3.5
Originally Posted by Ammako View Post
.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.
At least the wowinterface API has a compatibility endpoint that returns a list of compatible game versions. If you match 70300 with it, it will "return" the latest game versions, in the current case 7.3.5, not 7.3 or 7.3.2. (although wowi doesn't seem to update game versions for the patch increments, they're still on 7.3.0)
https://api.wowinterface.com/addons/compatible.json

Last edited by p3lim : 05-08-18 at 02:03 AM.
  Reply With Quote
05-10-18, 09:32 AM   #23
Ellypse
Storyline and TRP dev.
 
Ellypse's Avatar
AddOn Author - Click to view addons
Join Date: Aug 2014
Posts: 9
Originally Posted by p3lim View Post
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
after_script: bash release.sh -g 7.3.5
Oh I'm so dumb, it was in the packager's documentation on GitHub. Well, that works perfectly. Since I have a dedicated branch for BfA alpha builds I have also set the Travis config to 8.0 on this specific branch.
Thank you again ^^
  Reply With Quote
05-11-18, 03:18 PM   #24
yess
A Murloc Raider
AddOn Author - Click to view addons
Join Date: May 2008
Posts: 8
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
Success!

Creating GitHub release: https://github.com/zanony/ChocolateBar/releases/tag/v3.1.2
Error! (422)
{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Release",
      "code": "already_exists",
      "field": "tag_name"
    }
  ],
  "documentation_url": "https://developer.github.com/v3/repos/releases/#create-a-release"
}
After trying with
Code:
git tag v3.1.3 && push --tags
the packer did release to GitHub but took the wrong tag (the one before the current).

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.
  Reply With Quote
05-11-18, 04:36 PM   #25
yess
A Murloc Raider
AddOn Author - Click to view addons
Join Date: May 2008
Posts: 8
Originally Posted by p3lim View Post
I'll take a look at it, I haven't used github releases myself.
Thanks. If It's to much of a hassle don't worry as git hub releases are not that important for me either
  Reply With Quote
05-11-18, 05:03 PM   #26
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,646
Originally Posted by yess View Post
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?
Yes, but the script should delete the existing release on GitHub in case it already exists (force overwrite basically).
If that doesn't happen, report it on the packager repo.

Originally Posted by yess View Post
After trying with
Code:
git tag v3.1.3 && push --tags
the packer did release to GitHub but took the wrong tag (the one before the current).
That should not happen, report it on the packager repo.

Originally Posted by yess View Post
I noticed that the CurseForge link to the keywords substitutions has changed.
Thank you, I've updated the links.
  Reply With Quote
05-13-18, 04:00 PM   #27
nebula
A Deviate Faerie Dragon
 
nebula's Avatar
AddOn Author - Click to view addons
Join Date: Jan 2007
Posts: 14
Originally Posted by yess View Post
After trying with
Code:
git tag v3.1.3 && push --tags
the packer did release to GitHub but took the wrong tag (the one before the current).
You're using lightweight tags and tagged the same commit with both v3.1.2 and v3.1.3, git itself used the v3.1.2 tag to reference the commit. You should use annotated tags (add a message with -m) so there is an actual object for it.

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. 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 (Although it would be nice if they added new patch versions)

Last edited by nebula : 05-13-18 at 04:19 PM.
  Reply With Quote
05-15-18, 05:58 AM   #28
yess
A Murloc Raider
AddOn Author - Click to view addons
Join Date: May 2008
Posts: 8
Originally Posted by nebula View Post
You're using lightweight tags and tagged the same commit with both v3.1.2 and v3.1.3, git itself used the v3.1.2 tag to reference the commit. You should use annotated tags (add a message with -m) so there is an actual object for it.
Ah thanks. I usually use annotated tags but after the problem with the Github release I thought I try to tag the repo exactly like suggested in the guide.
  Reply With Quote
05-15-18, 02:53 PM   #29
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,646
Originally Posted by yess View Post
Ah thanks. I usually use annotated tags but after the problem with the Github release I thought I try to tag the repo exactly like suggested in the guide.
Corrected that, thanks for pointing it out.
  Reply With Quote
06-08-18, 11:07 PM   #30
KyrosKrane
A Murloc Raider
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 6
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.
  Reply With Quote
06-08-18, 11:24 PM   #31
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,646
Originally Posted by KyrosKrane View Post
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.
Externals are for telling the packager which libraries it should download for you.
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:
  Libs/LibStub: https://repos.wowace.com/wow/libstub/trunk
  Libs/CallbackHandler-1.0: https://repos.wowace.com/wow/callbackhandler/trunk/CallbackHandler-1.0
  Libs/LibDataBroker-1.1: https://repos.wowace.com/wow/libdatabroker-1-1
This would tell the packager to download those three libs and place them in the "Libs" subdirectory of your packaged addon. The first two are from SVN, the last one from Git (the packager is smart enough to figure out which is which).

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.

Last edited by p3lim : 06-08-18 at 11:26 PM.
  Reply With Quote
06-08-18, 11:30 PM   #32
KyrosKrane
A Murloc Raider
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 6
Thanks again for the awesome advice, I'll check it out!
  Reply With Quote

WoWInterface » Developer Discussions » Tutorials & Other Helpful Info. » Guide: Automagically package and publish addons

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off