GitHub integration
 

Hey All,

I've been working on github integration and was going to make a panel where authors would visit to make packages until funkydude suggested that it should be a webhook instead. Now that would be much more sexy in my opinion since it would require much less work for you all. Plus it would be less UI work for me, would just need a panel for you to generate a secret and give you the webhook url.

So if we do a webhook what would be a good way to pass extra data such as version, etc?

• Parse toc to grab version, title changes, grab changelog from github automatically (not sure if this is best for changelog, I know my commit messages arent always best for general public)
• Require some type of json config file like wowi-pkgr.json
• Any other ideas????

Title and Version from .toc please, please, please. Minion gets terribly confused when the .toc version and wowinterface version field aren't exact matches and this would guarantee similarity, and this would directly address that pain-point.

Re the changelog, someone intending to sync their packages that way, one would assume that the author would write the changelog with that in mind.

The changelog parsing is an awesome idea, and maybe you could parse only the descriptions of the pusshes if those are in a specific branch such as a release one.

I'm going to assume you're building a automatic packager, and in which case you don't really need Github, you've got your own repository system.

I'm going to pull most of, if not all of these ideas from the packager logic that CurseForge uses to allow uniformity between the two websites, making it even less of a pain to release on multiple sites (which was the whole reason I made the proxy tool).

CurseForge only has two options on it's website for the packager (per project), one to set the packaging/release schedule (on every commit or on tag creation).
For every commit, use the last tag and append the commitref. For tags, well, use the tag.
This is the only option exclusive to the website, and should default to tags.

The other option they have is creating a root directory for the addon. This should default to the name of the toc file (void the .toc extension).
IMO, if you default it like that, you don't even need this option present on the website, it can be set with a metadata file instead.

All of the other options they have are supplied in the form of a metadata file they call ".pkgmeta", a YAML-like markup file, more information on this here:
http://www.wowace.com/wiki/projects/pkgmeta-file/

Most notably, this file contains the following (incomplete) list of options:

• "package-as" - same as the root directory option present on the website
• "externals" - any embedded addons such as libraries, specified as a table (see the wiki page on wowace)
• "manual-changelog" - specifies a manual changelog, options being path and markup language for parsing (you could default to a 'git shortlog' or something)
• "ignore" - files/paths to ignore for the packager
• "move-folders" - for moving files around
• "required-dependencies" - this is used for the curse client, you could probably do the same for minion
• "optional-dependencies" - same as the above

Also, the CurseForge packager has substitutions for the packager, information here: http://www.wowace.com/wiki/repositor...substitutions/

Basically, it scans through all the files and replaces those keyboards with actual values, most notably @project-version@, used to replace the Version field in the .toc file.

As for the changelog markup support, markdown, bbcode and plaintext should suffice.


But keep in mind, unless you do this all-in it won't be a good option for us authors, solutions like my proxy tool would still be a superior alternative once set up.
Good to see some traction on this matter tho!

Basically, for the UI part on the website, you only need to supply the following (assuming you're doing exactly what I'm thinking):

• Release schedule, dropdown containing "disabled", "commit" and "tag"
• Checkbox for enabling off-site publishing on github (webhooks)
• Wiki links for the metadata file and keyword substitution stuff.

In case of the 2nd option, you might show additional information on how to set it up when it's enabled.
Other than that it's all back-end.

Edit: Both of my comments assume you're only going to support Git, I have no idea what else you'd need for SVN/mercurial should you choose to support that too.

If parity with Curse is being considered, you may want to take into account the new CurseForge stack. It's currently in use by WildStar, and WoW will be migrated to it at some point before the heat death of the Universe.

The main thing is that at least for WildStar, they use pkgmeta.yaml instead of .pkgmeta. This isn't likely to be a huge deal since they appear to use the same key structure, but it's something to keep in mind. http://wildstar.curseforge.com/docs/packaging

The new stack also uses GitHub webhooks, which from what I understand would then trigger the packager to generate a zip based on that commit/tag.

Thanks for all the suggestions so far guys.

Looks the the first order of business is building a token generator which can then be used for our current upload api and the packager / webhook I'm working on.

As for the pkgmeta.yaml, that looks fine to implement. I'd almost rather go with a pkgmeta.json but can do yaml to keep things the same.

Hows the webhook coming along? Is it possible to tag/release on github and have wowi automatically pack things up and publish the zip?

Not well :(. I think I was tackling this the wrong way trying for full github integration. It was taking so long I ended up moving on to other projects after I added our api token generator and created our API for uploading to wowinterface (https://api.wowinterface.com/addons/list.json). Sorry :(

I think I need to start simple and just support public github projects first and get the packager working instead of trying to support all repos (private included) by using githubs api. Just have a simple input area for the git repo details and a packager that works, first pass maybe even require a button press to trigger package. 2nd pass add webhooks to trigger building automatically using gearman, rabbitmq or maybe even use Jenkins hmmmm, create jobs via its api and then it already has the github monitoring.

I am interested in this project. It would make this site usable for me as an addon author.