Quantcast Guide: Automagically package and publish addons - Page 2 - WoWInterface
Thread Tools Display Modes
05-08-18, 01:45 AM   #21
Ammako
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Jun 2016
Posts: 256
.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,678
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 Deviate Faerie Dragon
AddOn Author - Click to view addons
Join Date: May 2008
Posts: 16
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 Deviate Faerie Dragon
AddOn Author - Click to view addons
Join Date: May 2008
Posts: 16
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,678
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 Deviate Faerie Dragon
AddOn Author - Click to view addons
Join Date: May 2008
Posts: 16
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,678
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 Deviate Faerie Dragon
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 10
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,678
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 Deviate Faerie Dragon
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 10
Thanks again for the awesome advice, I'll check it out!
  Reply With Quote
06-25-18, 11:51 AM   #33
KyrosKrane
A Deviate Faerie Dragon
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 10
Originally Posted by p3lim View Post
You can however add externals' files you want to ignore for the packaging, as it's the last thing it does.
This unfortunately seems incorrect. I spent some time trying to exclude the tests subdir from LibStub, and it wouldn't work. I finally figured out why. In the release.sh script, the processing for the "ignore" directive in the .pkgmeta happens first (starting at line 549), but when externals are checked out, the ignore list is cleared before processing each checkout (line 1232). The upshot is, the release script will not apply ignore directives in your .pkgmeta to the contents of externals.

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:
    - Libs/LibStub/tests

externals:
   Libs/LibStub: https://repos.wowace.com/wow/libstub/trunk
  Reply With Quote
07-01-18, 11:18 AM   #34
KyrosKrane
A Deviate Faerie Dragon
AddOn Author - Click to view addons
Join Date: Dec 2007
Posts: 10
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
  Reply With Quote
07-17-18, 02:05 AM   #35
AcidWeb
A Theradrim Guardian
 
AcidWeb's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 64
Code:
install: echo -e "[alias]\nclone = clone --insecure" > ~/.hgrc
Needed in .travis.yml if mercurial repositories are used. Dirty hack but it is not worth to invest time to fix it properly.
  Reply With Quote
08-01-18, 04:22 PM   #36
StormFX
A Wyrmkin Dreamwalker
 
StormFX's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2006
Posts: 57
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?
  Reply With Quote
08-01-18, 05:00 PM   #37
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,678
Originally Posted by StormFX View Post
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?
Travis CI is (basically) running a full Linux installation, you can install any software you need for testing or w/e on it, just as we're using pandoc for the packager.
  Reply With Quote
08-01-18, 05:03 PM   #38
StormFX
A Wyrmkin Dreamwalker
 
StormFX's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2006
Posts: 57
Originally Posted by p3lim View Post
Travis CI is (basically) running a full Linux installation, you can install any software you need for testing or w/e on it, just as we're using pandoc for the packager.
Right, but without third-party scripts, it doesn't actually validate anything.
  Reply With Quote
08-11-18, 09:30 AM   #39
Xruptor
A Flamescale Wyrmkin
 
Xruptor's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 106
Originally Posted by p3lim View Post
Travis CI Setup




To enable Travis CI for a project, find it in this list, then hit the big switch so it turns green,
then click the cogwheel next to it to continue with the setup.
p3lim I've recently registered for an account and have activated it. It syncs my repositories properly but I'm having issues with this guide. It looks like they've updated their website? The button above no longer exists on the default profile page. In fact I can't seem to find it anywhere.

Originally Posted by p3lim View Post

In here you'll want to disable "Build pull request updates" and enable "Build only if .travis.yml is present", like so:



The only thing that seems to be still there is the Environment variables portion of the guide. The top parts have been moved or are no longer a feature. Please let me know what I can do to properly activate this.
__________________
Click HERE for the ultimate idiot test.

if (sizeof(sadness) > sizeof(happiness)) { initDepression(); }
  Reply With Quote
08-11-18, 01:14 PM   #40
p3lim
A Pyroguard Emberseer
 
p3lim's Avatar
AddOn Author - Click to view addons
Join Date: Feb 2007
Posts: 1,678
Originally Posted by Xruptor View Post
p3lim I've recently registered for an account and have activated it. It syncs my repositories properly but I'm having issues with this guide. It looks like they've updated their website? The button above no longer exists on the default profile page. In fact I can't seem to find it anywhere.

The only thing that seems to be still there is the Environment variables portion of the guide. The top parts have been moved or are no longer a feature. Please let me know what I can do to properly activate this.
The only option you should need to enable now is the "Build pushed branches" in each repo's settings.
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)

Last edited by p3lim : 08-11-18 at 01:20 PM.
  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