Guide: Automagically package and publish addons - Page 3

p3lim · 08-01-18, 05:00 PM

Originally Posted by StormFX

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.

StormFX · 08-01-18, 05:03 PM

Originally Posted by p3lim

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.

p3lim · 08-11-18, 01:34 PM

Originally Posted by StormFX

Right, but without third-party scripts, it doesn't actually validate anything.

That is correct. If you want an example with tests/evaluations, see how Rainrider did it in his addon "oUF_Dispellable":
https://github.com/Rainrider/oUF_Dis...er/.travis.yml

(Sorry for the late response, I seem to have missed your reply.)

p3lim · 05-08-18, 01:59 AM

Originally Posted by Ellypse

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

.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

Ellypse · 05-10-18, 09:32 AM

Originally Posted by p3lim

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 ^^

p3lim · 05-11-18, 05:03 PM

Originally Posted by yess

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

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

I noticed that the CurseForge link to the keywords substitutions has changed.

Thank you, I've updated the links.

zork · 10-25-18, 06:36 AM

Thanks p3lim for providing this. I need some help.

I added the .travis.yml and the .pkgmeta to one of my addons in my github repo. Currently the .pkgmeta and the .travis.yml use CRLF as ending. Is that a problem? I told GIT bash for windows not to mess with line endings.

https://github.com/zorker/rothui/tre...w8.0/rVignette

I then used the git command you provided using git bash for windows in the git directory of rVignette.

I'm not sure but I think my whole repo got that tag?! Is that correct?

https://github.com/zorker/rothui/tree/v800.20181025

Once I started the git bash command I had to log into github and the tag completed.

But nothing else seem to have happened? What am I missing?

I had added the wowi token to the Travis page before. My travis page is all grey and says: There is no build on the default branch yet?

Ok I checked the travis request page. I can see some error messages now. Travis does seem to try to generate a new build when I commit with Github desktop to master. (The first two requests) Why is that?

*edit* Ohhh I see. It would run on any commit but when reading the config file would only react to branches that match the pattern.

That being said. To correct the error from my understanding I have to put the .travis.yml in the repo root right? What does that mean for the packager? Will he parse all directories and upload all of them at once? If I only make a change to one of the addons all will be updated? How do I do this for specific directories?

p3lim · 10-25-18, 07:11 AM

Originally Posted by zork

Thanks p3lim for providing this. I need some help.

I added the .travis.yml and the .pkgmeta to one of my addons in my github repo. Currently the .pkgmeta and the .travis.yml use CRLF as ending. Is that a problem? I told GIT bash for windows not to mess with line endings.

https://github.com/zorker/rothui/tre...w8.0/rVignette

I then used the git command you provided using git bash for windows in the git directory of rVignette.

I'm not sure but I think my whole repo got that tag?! Is that correct?

https://github.com/zorker/rothui/tree/v800.20181025

Once I started the git bash command I had to log into github and the tag completed.

But nothing else seem to have happened? What am I missing?

I had added the wowi token to the Travis page before. My travis page is all grey and says: There is no build on the default branch yet?

Ok I checked the travis request page. I can see some error messages now. Travis does seem to try to generate a new build when I commit with Github desktop to master. (The first two requests) Why is that?

*edit* Ohhh I see. It would run on any commit but when reading the config file would only react to branches that match the pattern.

That being said. To correct the error from my understanding I have to put the .travis.yml in the repo root right? What does that mean for the packager? Will he parse all directories and upload all of them at once? If I only make a change to one of the addons all will be updated? How do I do this for specific directories?

For reasons I do not understand, you are using a single repo for multiple projects, which is not how Git was intended to be used, thus no CI tool will be able to understand.
E.g, if you tag the repo (and tags only work on repo-level, as with branches), every project you have in that repo (as you've set it up) will get the same tag.

The packager and Travis expects Git to be used as it was intended; one repo per project, and each project has its own .travis.yml file at the root, and tagging the repo will trigger Travis/packager.

Aiue · 09-28-19, 01:03 PM

Right, it would appear I'm doing something wrong with git, and I can't quite figure out what, so I'm turning here for help. Even tagging exactly in the manner suggested in the op, I keep tripping this:

Code:

	if [ -z "$TRAVIS_TAG" ]; then
		# don't need to run the packager if there is a tag pending
		TRAVIS_TAG=$( git -C "$TRAVIS_BUILD_DIR" tag --points-at )
		if [ -n "$TRAVIS_TAG" ]; then
			echo "Found future tag \"${TRAVIS_TAG}\", not packaging."
			exit 0
		fi

Which means the packager will only run if I have no tag (as I currently have it configured to do that, as, well, it's gotta run on something.)

I'm sure there's something obvious I'm missing, but I'm stumped, so any help would be appreciated.

The repo in question is at https://github.com/Aiue/AQT, in case an extra set of eyes looking at stuff helps.

Aiue · 09-28-19, 02:38 PM

Originally Posted by Aiue

Which means the packager will only run if I have no tag (as I currently have it configured to do that, as, well, it's gotta run on something.)

Turns out this was the issue. Setting it to run on anything will cause this. I guess that's what I get for not following instructions explicitly and improvising.

p3lim · 08-07-20, 08:16 PM

DISCLAIMER

This guide has been deprecated in favour of GitHub Actions, as it's more integrated and (honestly) easier to set up.

A full guide is provided on the wiki for the packager itself. Direct link: https://github.com/BigWigsMods/packa...tions-workflow

devilArt · 08-17-20, 09:04 AM

Originally Posted by p3lim

DISCLAIMER

This guide has been deprecated in favour of GitHub Actions, as it's more integrated and (honestly) easier to set up.

A full guide is provided on the wiki for the packager itself. Direct link: https://github.com/BigWigsMods/packa...tions-workflow

hey p3limhow do I use "wowi API token" when I setup github action?

p3lim · 08-19-20, 03:48 PM

Originally Posted by devilArt

hey p3limhow do I use "wowi API token" when I setup github action?

1. Get a token from WoWInterface
2. Store the token as a secret for your project on GitHub, name it WOWI_API_TOKEN
3. Define WOWI_API_TOKEN as an environment variable in the workflow

How to get a WoWInterface token is documented in the packager readme, how to add GitHub secrets is documented in the wiki page for the action, and how to add it as an environment variable in the workflow is also documented there.