gamejolt / cli

GJPush

This is an experimental tool to upload builds to Game Jolt from the command line. It supports resuming an upload and creating builds/releases on the fly!

Usage

1. Download from https://github.com/gamejolt/cli/releases
2. Run from cmd / terminal:

   gjpush file
   

   where file is the path to the build you want to upload

Options

GJPush will prompt you for additionanl info it needs, but you can automate it by passing it in through options:

-t, --token=TOKEN        Your service API authentication token
-g, --game=GAME-ID       The game ID
-p, --package=PACKAGE    The package ID
-r, --release=VERSION    The release version to attach the build file to
-b, --browser            Upload a browser build. By default uploads a desktop build.

Advanced Options:
--chunk-size=MB          How big should the chunks the CLI uploads be. Defaults to 10.
--no-resume              Do not resume an existing upload. Start over if an upload already exists.

1. Token is your "password" to the tool, and can be provided to the tool in 3 ways:

   • The -t / --token parameter
   • An environment variable GJPUSH_TOKEN
   • A global credentials file located in your home directory, in .gj/credentials.json.
     The credentials file is a json containing a single key token. Looks like {"token":"your token here"}

   At the moment only testers are given a token, but when the tool is launched publicly, you can get one from your dashboard.

2. The game ID and package ID are available in the url of the manage game package page, for example:

3. The release is semver, looks like 1.2.3

Once all required options are specified, the upload can happen in a single command:

Example

Pushing version 2.0.1 as a desktop build for a game with ID 1 and package ID 2:

gjpush -t my-token -g 1 -p 2 -r 2.0.1 game.exe

To push a browser build, simply add the -b options:

gjpush -t my-token -g 1 -p 2 -r 2.0.1 -b game_html.zip

Want to help test?

Awesome! Send me an email at [email protected] with:

1. A link to your profile
2. A link to a game page

cli's Issues

GJ push command-line syntax not really powershell friendly

Now I'm not asking for a fix, as I could already cover this one up myself, but if GJPush is every Released to the public, this could be important to document

Since GJPush uses the switches like "-switch=value" in stead of "-switch value", the PowerShell script I wrote to quickly keep my updates for Kthura up went haywire, and I had to put the syntax I demonstrated below (note: I removed IDs and of course my token from this script, for obvious reasons).

$RELEASE="19.8.6-beta" 
$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN="???"
$GAMEID=0
$INSTALLER_ID=0
$NORM_ID=0

echo "Game ID: $GAMEID"

echo "Release is $RELEASE --- Make sure that is ok!"
pause

pushd
cd ../Releases
zip ../InstallerScript/Kthura.zip -9
popd

echo "gjpush -t=$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN -p=$INSTALLER_ID -r=$RELEASE -g=$GAMEID Kthura_Installer.zip"
echo "gjpush -t=$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN -p=$NORM_ID -r=$RELEASE -g=$GAMEID Kthura.zip"


gjpush "-t=$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN" "-p=$INSTALLER_ID" "-r=$RELEASE" "-g=$GAMEID" Kthura_Installer.zip
gjpush "-t=$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN" "-p=$NORM_ID" "-r=$RELEASE" "-g=$GAMEID" Kthura.zip

Without the quotations this wont work....

gjpush -t=$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN

Will make the rest of the parameters not being understood because my token contains the hashtag, meaning PowerShell will comment the rest out. In Linux and MacOS I could write

gjpush -t="$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN"

But PowerShell will not accept that. If it was without using the '=' this could be done the same on both Unix and PowerShell

gjpush -t "$SCYNDI_SUPDATEGAMEJOLT_CONSTANT_TOKEN"

I don't know if leaving out the '=' is a realistic solution (which Unix rules seem to want that anyway, and PowerShell was set up to follow these same rules), but if not, this issue could serve as a reminder of the woes PowerShell brings on this (which I prefer above cmd, to be honest).

Suggestion: Binary diffing to push new builds

Now I've been pushing my game a few times with both gjpush and with butler (the itch.io equivalent) and butler didn't even need half the time gjpush needed, but butler 'cheats' a little. Butler compares the newest push with the second-newest push and only uploads the data that has actually been changed, saving tons of time and bandwidth in the process. Not all countries have unlimited bandwidth (yet), so it is something to consider. I guess the hard part lies in the fact that Game Jolt has a more complicated set up with packages and releases which itch.io does not (when the filename/directory is the same it will start comparing and replacing automatically), still if there are some possibilities here, a lot of people could be grateful :)
I also wonder how Butler really manages to do this, since my game is basically one big packed file containing all the data with only a few extra files for executables and libraries, but still it appears to be able to do this based on the upload times, and also claiming that only 2% new data was changed, and since I use a packing system I designed myself, I deem it unlikely it knows how my package system works, but hey, I've seen crazier things.

If this is undoable in the way GJ is set up, we can still scrap this idea, but maybe we do need to give it some consideration. 😉

Suggestion: A few things that now must go through the site in the command line

Like the platform, run-file and even publishing as now it always ends up as a half-done draft.

gjpush --token=mytoken --game=mygameid --package=mypackage --release=1.2.3 --platform=Mac --executable=mygame.app --publish MyGame.zip

Is this possible to do?

Upload a build from a URL

Ability to specify a URL instead of a file to upload

Reject uploading a bigger build than you are permitted

Currently the backend rejects the build at the time of verification - when it's fully uploaded.
For the CLI, we can add a QoL feature to fail faster if the build is too big. We could also point to a useful email where one could request a higher limit.

Support for getting token from file or environment variables

It's very useful to be able to provide the token from a file or environment variable for CI tools like appveyor/circle/travis etc.

When provided through these methods it must not be echoed out to keep the log secure.

Suggestion: Multi-File support

/Volumes/Scyndi/GameJolt/cli/gjpush --token="TOKEN" --game=GAME --package=PACKAGE -r=0.0.0-test2 *.7z
Too many arguments! Maybe you need to escape the file name if it contains spaces?

I guess the "too many arguments" is thrown as Unix now automatically adds all files it can find suffixed with .7z but perhaps making this possible in one go, should be nice, since after all I am a Mac user myself, but if I can upload both the Mac version and the Windows version (and perhaps also the Linux version) in one go it would be a great improvement.

Support for collaborators

Currently the tool can only upload to games directly owned by the user whose token was provided.

It should support uploading builds to games the user collaborates on as well.

Archive validation before pushing

Currently the validation of the archive is done asynchronously in the backend and depends on the whole build to be uploaded first.

We could support that validation even before uploading by sending over just the file list before the upload

Successful upload, have some minor feedback

Managed to get a full run of a build/upload through Github actions 🎉 - very nice so far!

I'm just collecting a few of my notes here and I can re-raise them as separate Issues for tracking if you'd like.

1. I'd be keen to have more actions available through the CLI by having action verbs as part of the interface as opposed to just having the options.
   • e.g. $ gjpush upload to upload, $ gjpush whoami to validate my token, $ gjpush list to list releases
2. Currently I'm shipping the gjpush binary with my repo for CI/CD but it would obviously be easier for other users to just have a publicly maintained docker image with the latest CLI version and Git+LFS
   • I'd be happy to give you a snippet of my Github actions pipeline and help develop a pattern for other users if that helps?
3. +1 for the ability to publish via CLI - either through a CLI option or a separate command (#3)
4. Trying to upload with an invalid game id should probably result in an exit 1

Support for specifying launch options

To make builds publishable the developer needs to specify some launch options.

For desktop builds: which platforms are supported, and for each platform - which file is the main executable.file.
For browser builds: Browser dimensions, right click behaviour, etc.

Support for automatically publishing the release

The tool should be able to publish the release if it hasn't been published yet.

This should also support scheduling the release.

Handshake timeouts in quite large numbers

Above is a screenshot in which I ran a script packing the Mac version, Windows32 and Windows64 version and pushing it all using gjpush, and above we see Mac version and Win32 fail due to handshake failures (timeouts) and only windows64 being uploaded.
The failures do outrank the successes, mostly with a 1:3 ratio (sometimes worse).

Now this is a large game, and my computer is slow, but still I do not experience this issue on other internet tools I use, making me wonder if gjpush is to blame or not. It could be something to look at... :-/

What is "a weird looking response" supposed to mean?