Giter Site home page Giter Site logo

packager's People

Contributors

adirelle avatar ascott18 avatar cdagaming avatar funkydude avatar gethe avatar janpantel avatar johnnylam88 avatar meorawr avatar nebularg avatar nevcairiel avatar p3lim avatar pajlada avatar phanx avatar qartemist avatar rainrider avatar rubensayshi avatar talryn avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

packager's Issues

Set changelog title

Addon I'm trying to use packager with has icons in its title, defined in .toc:

## Title: .|TInterface\Addons\AllTheThings\assets\logo_32x32:0|t AllTheThings |TInterface\Addons\AllTheThings\assets\logo_32x32:0|t

It results in the fancy title in game:
image

But it also results in the not so fancy title in the auto changelog:
image

Is there an option I'm missing that could help override Title from the .toc (without the use of manual changelog)?
If not then I'm proposing to add such an option, either as a new field in .pkgmeta or just as an extra option for the packager itself. Or modify Title parsing in packager to exclude icons.

Question about action

@p3lim
Where do I put my WOWI api token when I use packager action?

According to README,

release.sh will attempt to load environment variables from a .env file in the topdir or current working directory. You can also edit release.sh and enter the tokens near the top of the file.

Is this .env file public?

localization error

 Copying: Locale/deDE.lua
    Adding deDE
    Error! Invalid output
           https://wow.curseforge.com/api/projects/313283/localization/export?lang=deDE&unlocalized=Ignore

This error is repeated for all languages.

If I copy this link, add the "&token={token}" token at the end and open it in the browser, then I see a page with the translation.
I copy the token that is recorded in release.sh cf_token, so I can be sure that the token is correct.
I did not make other changes to release.sh

Any ideas?

Lua @non-retail@ tag not commenting out on build

I'm not sure if I'm doing something wrong, but I double checked the tag, but this keyword is not getting commented out in lua files. It works in the toc and the @Retail@ keyword works in the lua files just fine.

    --@retail@
    local InterfaceIcons = self.GetFileDataRetail and self:GetFileDataRetail()
    --@end-retail@

    --@non-retail@
    local InterfaceIcons = self.GetFileDataClassic and self:GetFileDataClassic()
    --@end-non-retail@

The above is the code I have in my file (I had to add the check before the function call because the keyword not commenting this out, even though it commented out the file that contained the functions was breaking my addon.

The classic version ends up looking like this:

    --[===[@retail@
    local InterfaceIcons = self.GetFileDataRetail and self:GetFileDataRetail()
    --@end-retail@]===]

    --@non-retail@
    local InterfaceIcons = self.GetFileDataClassic and self:GetFileDataClassic()
    --@end-non-retail@

But the retail version just stays the same as the source code.

Again, I'm not sure if this is a bug or maybe me doing something wrong?

Docker image

Would you be opposed to keeping a Dockerfile in this repo and setting up automatic updates for an "official" Docker image?
This would simplify (and speed up) running the packager on CIs using Docker like CircleCI.

I could create the Dockerfile (and even provide a sample config for CircleCI) and help set up the automation with Docker Hub for the image (I could also manage this, but that would require collaboration access to the repo).

I've got this set up locally already, but it'll require manually updating the Docker image every time the script changes, which is what I'm trying to get rid of.

Error with awk in localization in the Alpine environment

I'm using the packager via a GitHub action and I receive the following error:

  Copying: Locale/enUS.lua
    Adding enUS
    awk: bad regex '^{"error': Invalid contents of {}

The localization is never added due to that error.

This error is caused because the version of awk with Alpine doesn't support the syntax in the existing code. If I run my action referencing the previous commit before the update to the Alpine environment, it runs without errors and has the localization.

If you are going to use Alpine, I think the awk code needs to be updated to reflect the difference.

Better changelogs

Need to add back in finding the previous tag and restricting the log to that range.

Sometimes the packager fails to detect that a Github release already exists

Take a look at this build for example where two sets of packages are created (retail and classic):

https://travis-ci.com/2072/H-H-T-D/builds/125778315

After the retail package release creation, the packager creates the -classic packages and attempt to recreate the release instead of updating it. It seems to be a random issue since I made 3 other successful releases before...

It's probably Github's fault but could it be possible to trap this error and update the release instead of failing? (maybe by checking the date of the release, say if it's less than 5 minutes old...)

Creating GitHub release: https://github.com/2072/H-H-T-D/releases/tag/2.4.9.3
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"
}

Inconsistent handling of alpha/beta/release status

(Full disclosure: I'm not a BigWigs developer, so this request is from my viewpoint as an external addon author. Thanks for providing this tool to everyone! :) )

The release script has some inconsistent handling of alpha, beta, and prerelease status across different upload targets. The base script only supports alpha (untagged) and release (any tag) settings, but it attempts to parse the tag later on and set alpha, beta, or prerelease status for individual repositories. This results in a file being mistagged across different repositories.

Here's the relevant code. First, at line 854, it sets alpha status based on whether the tag is present or not:

[ -n "$tag" ] && alpha="non-alpha" || alpha="alpha"

At line 2126-2145, it sets the Curse upload status to alpha, beta, or release based on parsing the tag.

	# Upload to CurseForge.
	if [ -n "$upload_curseforge" ]; then
		# When packaging is triggered on your repository, the generated file’s release type will
		# automatically be set based on two factors:
		#   1) If configured to package all commits, the latest untagged commit will be packaged
		#      and will be marked as an alpha.
		#   2) Otherwise, when a tagged commit is pushed, it will be flagged as either alpha, beta,
		#      or release depending on the tag itself:
		#        - If the tag contains the word "alpha", it will be marked as an alpha file.
		#        - If instead the tag contains the word "beta", it will be marked as a beta file.
		# https://authors.curseforge.com/knowledge-base/projects/3451-automatic-packaging
		file_type="alpha"
		if [ -n "$tag" ]; then
			if [[ "${tag,,}" == *"alpha"* ]]; then
				file_type="alpha"
			elif [[ "${tag,,}" == *"beta"* ]]; then
				file_type="beta"
			else
				file_type="release"
			fi
		fi

Next, for Github, it's processed at line 2325. The status is set to pre-release only if the tag contains "beta" - alphas are uploaded to GH as production releases.

"prerelease": $( [[ "${tag,,}" == *"beta"* ]] && echo true || echo false )

The recommended fix is to move the CurseForge logic an initial status setting (effectively replacing line 854) at the start of the script. Determine early on whether this build is alpha, beta, or release. Then, update the CurseForge section to set the CF file_type value based on the setting. Finally, update the Github setting to tag both alpha and beta builds as prerelease.

The upshot of these changes is:

  • If the build is untagged, treat as alpha.
  • If the build is tagged, parse the tag for the "alpha" keyword and mark as alpha if found.
  • If the build is tagged, parse the tag for the "beta" keyword and mark as beta if found.
  • If the build is tagged and doesn't include the alpha or beta keywords, mark as release.

A related change may be required to the automated changelog handling (lines 1785-1813). The changelog should record changes as follows:

  • If the build is alpha or beta, show all changes since last alpha, beta, or release (whichever is latest)
  • If the build is release, show all changes since last release

This also resolves the issue of the release changelog only showing updates since the last alpha release.

Error with quotation marks in changelog

If the changelog contains quotation marks, and the $releasedir path contains spaces, uploading to WoWInterface fails.

https://github.com/BigWigsMods/packager/blob/master/release.sh#L1719

The problem is that the changelog field parameter isn't quoted. If I put this directly in the curl call:

-F "changelog=<$pkgdir/$changelog"

... then it works. It also works if I create a space-free symlink to the World of Warcraft directory and work under that instead of the real path.

I attempted several dozen variations on quote styles, escaping quotes, string concatenation, cat | sed to escape the actual quotes in the changelog text, etc., but only managed to shift the point of failure around.

Unfortunately escaping the changelog with HTML entities isn't a solution because the ampersand gets double-escaped (by curl or WoWI, I'm not sure which) and &quot; gets displayed literally on the website.

tag inside tag

Hello, im not sure if this is just unsupported but I made this commit doadin/Plexus@8f5bfcd to my repo and it resulted in a error.

--[===[@non-retail@

        if (showOffline or online) and (showWrongZone or curMapID == mapID) then

            hideGroup[subgroup] = nil

--@debug@

        elseif curMapID ~= mapID and not showWrongZone then

            hideGroup[subgroup] = (hideGroup[subgroup] or "") .. " ZONE"

        elseif not online and not showOffline then

            hideGroup[subgroup] = (hideGroup[subgroup] or "") .. " OFFLINE"

--@end-debug@

        end

--@end-non-retail@]===]

the end after --@ end-debug@ was not removed from retail even though its before the --@ end-non-retail@]===] as if the --@ end-debug@ closed the --@ end-non-retail@]===].

Support localization in TOC

@localization(key="MyAddon Description")@ doesn't work right now. Keeping the exported locale file around until we get to externals would allow you search the file several times (or use the entire thing) without having to pull it each time (which takes for fucking ever)

nolib upload curseforge support with API's parentFileID parameter

Hello,

I noticed that the nolib packages are not uploaded to curseforge. From the commit log it was disabled several years ago because it could not be handled via Curse's API.
However now it seems that one can provide a parentFileID parameter to upload a file under another:

https://authors.curseforge.com/knowledge-base/projects/529-api

{
    changelog: "A string describing changes.", // Can be HTML or markdown if changelogType is set.
    changelogType: ["text", "html", "markdown"], // Optional: defaults to text
    displayName: "Foo", // Optional: A friendly display name used on the site if provided.
    parentFileID: 42, // Optional: The parent file of this file.
    gameVersions: [157, 158], // A list of supported game versions, see the Game Versions API for details. Not supported if parentFileID is provided.
    releaseType: "alpha", // One of "alpha", "beta", "release".
    relations: {
        projects: [{
            slug: "mantle", // Slug of related plugin.
            type: ["embeddedLibrary", "incompatible", "optionalDependency", "requiredDependency", "tool"] // Choose one
        }]
    } // Optional: An array of project relations by slug and type of dependency for inclusion in your project.
}

Could this be (re)implemented?

Not updating WoWUI or Curse

I must be missing something obvious.
@p3lim
I'm setting up the workflow on SimpleCoords
And I created a release.
Updated GitHub, but I don't see any action or errors relating to WoWUI or Curse.

I set up the secrets (at the project level).

Thoughts?

Release.sh not uploading release file to github

I'm very new to this, and for the moment I just want to have the release packaged up to github where my source is. I'm trying to use CurseBreaker to manage my mods. I've configured my github actions using the template provided to do release automation. I don't see any errors in the flow that results but it doesn't seem like the file is being updated to github. I'm sure I'm missing something simple but I just can't figure this out.

my mod is here: https://github.com/mjbrowns/SoundMapper

Packager Not Ignoring Files in Externals

While testing my widget library as an external in Masque, I noticed that the included external that was packaged includes files that I explicitly set to ignore in the .pkgmeta of the library. I'm no pro at shell, but I think I might have it narrowed down to this bit of code in the parse_ignore function:

				if [ -d "$checkpath/$pattern" ]; then
					pattern="$copypath$pattern/*"
				elif [ ! -f "$checkpath/$pattern" ]; then
					# doesn't exist so match both a file and a path
					pattern="$copypath$pattern:$copypath$pattern/*"
				fi

If it's parsing the root add-on, the files on the ignore list exist relative to the root directory. However, when parsing externals, it's trying to find their ignored files in the root add-on directory as well. I tested this by echoing $ignore as it parsed and noticed that it listed a bunch of the same files multiple times.

I'm guessing that the issue is that there's no else section of that statement block that tells it to use the $copypath$pattern if the file does exist, causing it fall back to just $pattern. This seems to fix it (like I said, I'm no pro at shell, so if it's bad, sorry. :p)

				if [ -d "$checkpath/$pattern" ]; then
					pattern="$copypath$pattern/*"
				elif [ ! -f "$checkpath/$pattern" ]; then
					# doesn't exist so match both a file and a path
					pattern="$copypath$pattern:$copypath$pattern/*"
				else
					pattern="$copypath$pattern"
				fi

Handling of Nested Keywords

I'm not sure if there is an easy fix or if it even matters in the long run, but nested keywords in certain file types can cause problems. Notably, XML. Take for example the following:

	<!--@no-lib-strip@-->
	<Include file="AceAddon-3.0\AceAddon-3.0.xml"/>
	<!--@retail@-->
	<Script file="LibDualSpec-1.0\LibDualSpec-1.0.lua"/>
	<!--@end-retail@-->
	<!--@end-no-lib-strip@-->

If one was packaging a no-lib, Classic release, you end up with malformed XML:

	<!--@no-lib-strip@
	<Include file="AceAddon-3.0\AceAddon-3.0.xml"/>
	<!--@retail@
	<Script file="LibDualSpec-1.0\LibDualSpec-1.0.lua"/>
	@end-retail@-->
	@end-no-lib-strip@--> <!-- Note the plain text. -->

I imagine that the simplest solution is to just not nest keywords in XML, etc, files. Issues are avoided easily enough by putting problematic lines in the ToC:

# Libraries
Libs\Libs.xml
#@no-lib-strip@
#@retail@
Libs\LibDualSpec-1.0\LibDualSpec-1.0.lua
#@end-retail@
#@end-no-lib-strip@

Though it might not be a bad idea to at least mention this is the wiki (unless it's there somewhere and I missed it). In any case, I just thought I'd mention it. Thanks!

WoWInterface uploading for both game versions

CurseForge handles multiple versions per project quite well (e.g. if you upload both classic and retail for the same version of a project, it'll display them separate), but WoWI doesn't handle this well.

An option to not upload to an already configured (by TOC) remote (e.g. the oposite of the -p and -w flags, maybe uppercase) would help this issue in the short run.

Handle nested externals

Probably not hugely important, but doesn't seem too hard to do. Just need to tweak the vars for where to put the external. Would also be beneficial to move .pkgmeta parsing to a function to cut down on code duplication

Escape literals in author names

The packager gives an error when the author has special characters in the name, like Myrroddin/Sygon. It then fails to properly copy the files for packaging.

https://github.com/Myrroddin/libaboutpanel-2.0/runs/1619223003?check_suite_focus=true

Copying files into .release/LibAboutPanel-2.0:
    Copying: lib.xml
  sed: -e expression #4, char 30: unknown option to `s'
    Copying: LibAboutPanel-2.0.toc
  sed: -e expression #4, char 30: unknown option to `s'

The full sed posted by meorawr:

sed 
 -e s/@project-revision@/37/g 
 -e s/@project-hash@/5912b80d25c5779c566a66c2e8e8f1f94d14127d/g 
 -e s/@project-abbreviated-hash@/5912b80/g 
 -e s/@project-author@/Myrroddin/Sygon/g 
 -e s/@project-date-iso@/2020-12-28T22:00:11Z/g 
 -e s/@project-date-integer@/20201228220011/g 
 -e s/@project-timestamp@/1609192811/g 
 -e s/@project-version@/1.0.14/g 
 -e s/@file-revision@/26/g 
 -e s/@file-hash@/5d62d4c981e90f7a476b651e330c66fb80b124a8/g 
 -e s/@file-abbreviated-hash@/5d62d4c/g 
 -e s/@file-author@/myrroddin/g 
 -e s/@file-date-iso@/2019-11-19T13:49:58Z/g 
 -e s/@file-date-integer@/20191119134958/g 
 -e s/@file-timestamp@/1574171398/g

$project-version is empty when using untagged git commit

My head currently is a few commits ahead of the last tag, but the script doesn't seem to be able to create a version number based on the commit ID when not built against a tag.

The wiki states;

@project-version@
Turns into an approximate version of the project. The tag name if on a tag, otherwise it's up to the repo. :SVN returns something like r1234 :Git returns something like v0.1-873fc1 :Mercurial returns something like r1234.

However, my release zip folder has no version attached, and the .toc version which is set by @project-version@ is blank.
I'm using the -d argument, and nothing else.

A normal build built on a tag returns

Packaging SurroundFix
Current version: v3.6
Previous version: v3.5
Build type: retail non-alpha non-debug
Game version: 9.0.1

Whereas a build against an arbitrary commit returns

Packaging SurroundFix
Build type: retail alpha non-debug
Game version: 9.0.1

It seems that for whatever reason, when building from an arbitrary commit it doesn't populate the project-version value at all.
I would have expected it to return a version based on the current git commit, or at the very least something based on the previous tag. Having it be totally blank definitely feels like there's an error there.

Checking out the tag builds as expected.

Automatic Docker image builds

The automated builds on Docker Hub aren't working at all, and I proposed building and pushing with a 3rd party CI/CD like Travis or Circle a while ago to @nebularg on IRC.

This is obviously not my repo, but I "maintain" the Docker image of it, which makes this problematic: I can't add a build system pointed at/from this repo from my Travis/Circle account, and you can't push to my account on Docker Hub. Not sure how to resolve this.

Feature Request: Skip gitignore entries

Hi!

I'm writing an addon in MoonScript so I have a src directory and a build directory. My build directory is in the .gitignore file and this causes the contents not to be zipped. Right now I am mitigating this by running a git add in the Github Actions before doing the packager step.

I would like to request an option for listing entries that are ignored by SCM but required for packaging. To be honest, I don't think it should look at the gitignore entries at all but look at the ignored entries in the .pkgmeta only.

changelog processing is different from curseforge packager (for manual changelog), on curseforge

CF packager:
https://www.curseforge.com/wow/addons/dynamicboxer/files/2784081

changelog is as the original txt file
( https://github.com/mooreatv/DynamicBoxer/blob/master/ChangeLog.txt )

Bigwigs:
https://www.curseforge.com/wow/addons/dynamicboxer/files/2791311

lines are collapsed into paragraph
(and isn't doing markdown either)

is there an option to not process the manual changelog or to process it the same way as cf's packager?

Create -nolib packages

Follow the enable-nolib-creation .pkgmeta directive (default on). Maybe just for tags.

Easiest way is probably to built the list of paths used while doing the externals and excluding them from the zip (zip -X -r $archive $contents -x $libdirs)

upload error

release.sh: command substitution: line 2093: syntax error near unexpected token `<'
release.sh: command substitution: line 2093: `                                 mapfile -t V < <( echo "$_cf_versions" | jq -r --argjson v "$game_version_id" '.[] | select(.id as $x | $v | index($x)) | .name' 2>/dev/null )'

SVN tag URLs in pkgmeta require different syntax then CF packager

SVN tag URLs require a different syntax in the CF packager and in this script.

CurseForge compatible:

externals:
  LibStub: https://repos.wowace.com/wow/libstub/tags/1.0

release.sh compatible:

externals:
  LibStub:
    url: https://repos.wowace.com/wow/libstub/trunk/
    tag: 1.0

Neither option works on both. The first one has release.sh attempt to access the repo as Git, and the second has CurseForge pull in trunk instead of the tag.

Can we get the first variant supported by release.sh, so that the same syntax can be used on both?
Ideally it could perhaps attempt to probe the URL for the repo type, instead of guessing from the URL structure.

How exactly does the -g arg work?

To build for classic, my project currently has this in the GitHub action;

  - name: Package and Release for Classic
    uses: BigWigsMods/packager@master
    with:
      args: -g 1.13.5 -w 25252

I'm assuming that if -g is any version that is classic (1.13.x), then the @non-retail@ tags will be used instead of @retail@, correct?

After poking around the script, I also noticed there is a shortcut for classic release in -g classic. Am I right in assuming that this reads the @non-retail@ toc interface version to get the version if this argument is used?

Finally, is there any reason why -g 1.13.5 is used in the wiki example for a classic build rather than -g classic?
Are there any downsides to using -g classic over -g 1.13.5?

Thanks!

EDIT: Also this isn't strictly related to the above but I figure it's better asking here than opening another issue - Am I right in thinking that if the HEAD is not tagged, then it will build the current HEAD commit as an alpha build?

Broken pipe error with toc formatting

/home/runner/work/_actions/BigWigsMods/packager/master/release.sh: line 942: echo: write error: Broken pipe
/home/runner/work/_actions/BigWigsMods/packager/master/release.sh: line 958: echo: write error: Broken pipe
/home/runner/work/_actions/BigWigsMods/packager/master/release.sh: line 984: echo: write error: Broken pipe

The TOC file is;

## Interface: 90005
## Interface-Classic: 11306
## Interface-BC: 20501

Looser yaml support for pkgmeta?

YAML explicitly disallows tabs. However, the WowAce/Curseforge packager is lax about this and accepts pkgmeta files which have been indented with tabs. It's thus possible to have a pkgmeta which works fine for Curseforge but e.g. doesn't load any externals when packaged with this.

I noticed this in DropTheCheapestThing and have since fixed my pkgmeta there.

This is 100% not necessary, but 🤷‍♂

game_version variable taint

When uploading to WowInterface, the game_version varaible gets tained here: https://github.com/BigWigsMods/packager/blob/master/release.sh#L2306

Which when uploading to wago, causes it to use the tainted variable as a release, which wago then marks as invalid.

Logs:

Uploading <Addon>-bc.zip (2.5.1 release) to https://wow.curseforge.com/projects/<id>
Success!

Uploading <Addon>-bc.zip (2.05.1) to https://www.wowinterface.com/downloads/info<id>
Success!

Uploading <Addon>-bc.zip (2.05.1 release) to Wago
Error! (422)
{"message":"The given data was invalid.","errors":{"supported_bc_patch":["The selected supported bc patch is invalid."]}}

Changelogs question

Is there any way to disable changelog generation or have two seperate changelogs for classic and retail build?

So far im just using manual-changelog option but this is kinda annoying as it deletes all my previous changelog text on WoWInterface. And setting wowi-create-changelog=no doesn't seem to do anything.

Feature request: option to ignore manual-changelog when there is no tag

I like to have a "clean" changelog for beta and release that I write myself (where only end user visible changes are listed) but I also like to have commit logs for alpha packages.
The result is that I often forget to edit .pkgmeta when tagging a release or when pushing after a release...

Would it be possible to add a simple command line argument to ignore the .pkgmeta manual-changelog: directive when there is no tag?

Thanks!

Unable to run locally

When attempting to run locally I receive the following script error.

 tek (automate-release)
/mnt/d/World of Warcraft/_classic_/Interface/AddOns/DruidBarClassic » sh .release/release.sh
.release/release.sh: 167: .release/release.sh: Syntax error: redirection unexpected

Network issue fallback

Everything from pulling repos to localizing to uploading the zip is a one-off operation. Need to add some retry functionality for timeouts or connection issues, atleast for tags. Having to pull up the build and manual run it again isn't terrible, but full automation is nice.

Not getting a Classic build following post October 3

Hi All,

I had the following two lines in my .travis.yml file:

- curl -s https://raw.githubusercontent.com/BigWigsMods/packager/master/release.sh | bash; if [[ $? != 0 ]]; then TRAVIS_TEST_RESULT=1; fi
- curl -s https://raw.githubusercontent.com/BigWigsMods/packager/master/release.sh | bash -s -- -g 1.13.5 -m .pkgmeta -w XXXXXX ; if [[ $? != 0 ]]; then TRAVIS_TEST_RESULT=1; fi

My build process would create two versions of the mod. I used to get a 'version.zip' and a 'version-classic.zip' I'm now getting two 'version.zip' files. None of the non-retail substitutions are occurring and the -w tag is also being ignored. This was last working on a build I completed two days ago (October 3)

I did notice that there are some 'classic=' stuff in the new file. Do I need to change the command line to get the old functionality back?

Commented out externals are still checked out

If you comment out an external library within a pkgmeta file and then run the deploy script, it'll will still be checked out. In this case it will be pulled into # libs as the folder.

package-as: ExampleAddon

externals:
  # libs/AceAddon-3.0: https://repos.wowace.com/wow/ace3/trunk/AceAddon-3.0

As a workaround you can just delete the line.

line 1255: wait: pid <N> is not a child of this shell

Posting here because my understanding of Linux and bash is insufficient to have any idea how to investigate this problem. Verified that it happens with your version (at c716789), so it's not related to any changes I've made.

./release.sh: line 1255: wait: pid 15572 is not a child of this shell

Here's the command I entered:

./release.sh -t ../Broker_Reincarnation -d

And here's the full output:
https://gist.github.com/Phanx/00df7dd02800a648600a5c1c7705ae6a

If I go check the .release directory, all the files (including externals) are in the proper location. If I comment out lines 1255-1257 and re-run the command, no error is given, and a ZIP file is successfully created with all externals.

# Handle external repo errors
set -o monitor
handle_chld() {
    for i in ${!external_pids[*]}; do
        pid=${external_pids[i]}
        if ! kill -0 $pid &>/dev/null ; then
#           if ! wait $pid; then
#               external_error=1
#           fi
            unset external_pids[i]
        fi
    done
}
trap handle_chld CHLD

The related .pkgmeta file can be seen here:
https://github.com/Phanx/Broker_Reincarnation/blob/master/.pkgmeta

The same thing happens with any other addon I tested on; I just used this one for the ticket since its list of libs is the shortest.

Linux Mint 17.3 (based on Ubuntu 14.04) with bash 4.3.11. If any other details would be helpful, let me know what they are.

CurseForge upload fails with big CHANGELOGs

When the ChangeLog size has more than ~2kilobytes (approximately: 3k fails and less than 2k does not fail) CurseForge upload fails returning:

Error! (400)
{"errorCode":1002,"errorMessage":"Error in field metadata:\nInvalid JSON."}

Tested in debian 10.0 and in windows+cygwin:
I am not sure if this is a CurseForge or a packager issue, but its definitively problematic, a 2kilobytes limit is not so big.

[Request] Check for Github releases for externals

If an external links to a github repo, I think it would be useful to check if it has uploaded releases (like if they too use this packager) and optionally use that instead of the repo download.

--@non-retail@ / --@end-non-retail@ not being commented out when packaging retail

I have some code that needs to be split between packaging retail and non retail. When building classic it correctly adds comments between the retail / end-retail tags, but when building retail it does not comment out the non-retail tags. I've tried building both without specifying a game version and when specifying game version as the latest retail (9.0.1) and neither works to ever comment out code bracketed by non-retail / end-non-retail tags.

Am I missing some magic sauce to make retail builds not include non-retail tags?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.