If its Git, just push two both repos at the same time, its trivial to setup with most Git clients.
External repos have never worked flawless with the current packager, so I wouldn't hold my breath for a quick fix, considering they are working on a new platform which should embrace external repositories and promote them to full functionality.
Seems to be having issues again. I just tagged a new release ("v1.9.6") of Rundown, and it's responding with:
Joining all threads
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.6'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.0'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.6.1'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
There's more, but it gets aged off the webpage before I can capture the text. It then proceeds to repackage every tag and every commit in the project.
That reminds me, I need to stop putting a redundant 'v' in front of the version string.
Seems to be having issues again. I just tagged a new release ("v1.9.6") of Rundown, and it's responding with:
Joining all threads
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.6'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.0'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.6.1'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
There's more, but it gets aged off the webpage before I can capture the text. It then proceeds to repackage every tag and every commit in the project.
That reminds me, I need to stop putting a redundant 'v' in front of the version string.
Sorry - been at BlizzCon. I'll try to get this looked at tomorrow.
I have a new project GridLayoutByRole for which the packager refuses to create packages despite my attempts at tagging the repository.
For Git, you need to create the tags locally and push them separately from the code commits. You can't create a tag via the web page like you can for Subversion.
No, I'm aware of how to push tags from my local repository to the Git repository on CurseForge. The problem is that when I push my tag, nothing happens. My project is in some state of limbo where it won't package because it's not approved, but it's not approved because I have no packaged files. I don't know how to resolve it.
I don't see a single tag in your repository. Are you sure you pushed them?
Also, for the packager to work, you need to create an annotated tag (git tag -a)
Yes, I deleted the tags because they weren't doing anything and I wanted to re-tag a "1.0" release from the latest sources. Yes, I created annotated tags.
The problem of "latest tag is not the latest/default download" seems to have reared its ugly head again.
It might even be fallout from the "rebuild ALL THE THING" problem; if each tag is being rebuilt in parallel, then whatever tag happens to be the last one to finish would have the most recent timestamp on its file.
At the moment, CC 5.1.1.820 keeps trying to offer a very old version as the latest.
edit: Ooooh, I wonder if shifting all the tags to be local tags, and only pushing a single "latest" tag would inhibit this problem? Imma try that once apt-get finishes molesting my bandwidth.
Now that I've finally gotten TortoiseGit to work correctly when TortoiseSVN is also installed, I'm switching most of my SVN repos to Git, because (a) GitHub is just really nice, and (b) manually uploading files to WoWI takes way fewer clicks and page loads than manually uploading files to Curse so my release process will now require slightly less effort.
However, one of my addons is not getting packaged. Several other of my addons that have never had repos on GitHub have gotten packaged just fine, so I'm pretty sure this one is not working because I used to (several years ago) have an SVN repo for it on CurseForge. I have double- and triple-checked that the repo is set to package on beta and release, and have pushed the repo, including a tag that GitHub correctly noticed and packaged, to Curse twice. There's no new ZIP, and the packager status page just says "no data available".
Nah. There's an issue that's been around since last November where the job that tells the packager to do its thing simply flakes out every once in awhile. Apparently, it's getting worse if you've been hit two times in a row on the same project. I manually queued it, and you now have a new zip.
I can't wait to get the hell away from that broken POS.
External repos have never worked flawless with the current packager, so I wouldn't hold my breath for a quick fix, considering they are working on a new platform which should embrace external repositories and promote them to full functionality.
There's more, but it gets aged off the webpage before I can capture the text. It then proceeds to repackage every tag and every commit in the project.
That reminds me, I need to stop putting a redundant 'v' in front of the version string.
Sorry - been at BlizzCon. I'll try to get this looked at tomorrow.
For Git, you need to create the tags locally and push them separately from the code commits. You can't create a tag via the web page like you can for Subversion.
Also, for the packager to work, you need to create an annotated tag (git tag -a)
It might even be fallout from the "rebuild ALL THE THING" problem; if each tag is being rebuilt in parallel, then whatever tag happens to be the last one to finish would have the most recent timestamp on its file.
At the moment, CC 5.1.1.820 keeps trying to offer a very old version as the latest.
edit: Ooooh, I wonder if shifting all the tags to be local tags, and only pushing a single "latest" tag would inhibit this problem? Imma try that once apt-get finishes molesting my bandwidth.
It has a file for 1.1 build just an hour ago? Is there anything else missing?
Sometimes it can take a couple of minutes if its busy with another project at the time.
Sounds like the hook to notify the packager is somehow missing for his repository.
Can that please be fixed? I don't want to have to bug other people to make a package each time I tag a new release.
Now that I've finally gotten TortoiseGit to work correctly when TortoiseSVN is also installed, I'm switching most of my SVN repos to Git, because (a) GitHub is just really nice, and (b) manually uploading files to WoWI takes way fewer clicks and page loads than manually uploading files to Curse so my release process will now require slightly less effort.
However, one of my addons is not getting packaged. Several other of my addons that have never had repos on GitHub have gotten packaged just fine, so I'm pretty sure this one is not working because I used to (several years ago) have an SVN repo for it on CurseForge. I have double- and triple-checked that the repo is set to package on beta and release, and have pushed the repo, including a tag that GitHub correctly noticed and packaged, to Curse twice. There's no new ZIP, and the packager status page just says "no data available".
I can't wait to get the hell away from that broken POS.
http://wow.curseforge.com/addons/anyfavoritemount/repositories/mainline/packager/