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)

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.

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.

Basically, it scans through all the files and replaces those keyboards with actual values, most notably @[email protected], 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!

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.

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.