Pushing builds with springboardvr-cli

The only command that you need to remember is springboardvr-cli push

springboardvr-cli push directory game:channel


  • directory is what you want to upload. It can also be a .zip file.
  • game is the project you're uploading (to get the name of your games run springboardvr-cli status)
  • channel is which slot you're uploading it to
    • Currently only windows is available.

Okay, show me

If you push the same directory twice:

  • The first push will take some time, all data actually needs to be uploaded

  • The next pushes will be almost instantaneous, since nothing changed

These are two extreme cases — most of the time, you'll be somewhere in the middle, with maybe 5% to 20% fresh data in a push, saving 80% to 95% (more with compression) of your data/time/internet bandwidth.

Pushing to the same channel again will update that file, once the build is processed.

Specifying your own version number

By default, the SpringboardVR backend will generate a constantly-increasing integer version number for your builds, for each channel.

However, if you're already generating your own build number, you should pass it to springboardvr-cli with the --userversion option:

springboardvr-cli push mygame gamename:windows --userversion 1.1.0

You can also instruct springboardvr-cli to read the version number from a given file, if it fits your workflow better:

springboardvr-cli push mygame gamename:windows --userversion-file buildnumber.txt

The buildnumber.txt file should contain a single line with the version or build number, in UTF-8 without BOM.

User-provided version numbers don't have any particular format - the ordering SpringboardVR uses is the one builds are uploaded in.

Validating a build

Before pushing a build it is a good idea to validate the folder you will push. This command will check the manifest (if you have one) and walk through the folder to find the target executable.

springboardvr-cli validate mygame

Where mygame is the location of your game. This should provide some information about the build and how it will be launched. More information about validation can be seen here.

Launching a Build

Note: This is an experimental feature.

If you want to validate a build was pushed correctly first check its status with;

springboardvr-cli status mygame

Where mygame is the 'slug' for your game. This command should provide a table of the channels, uploads, builds, build status' and versions of your game.

Once the build status is complete you can fetch the game to your machine with the command:

springbaordvr-cli fetch mygame:channel destination


  • mygame is the 'slug' of the game you are fetching.
  • channel is which slot you are uploading to (windows only for now)
  • destination is the location to download the game to. It should be an empty directory.

Now try to launch that game with;

springboardvr-cli launch game_folder mygame:channel


  • game_folder is the folder holding the newest install of the game,
  • mygame is the slug of the game to be launched, and
  • channel is the channel of the game to be launched (windows!).

If game and channel are not provided the cli will list the games you develop and prompt you to enter the game and channel.

This launch will only work if game_folder contains the latest build for the given game from the SpringboardVR server.

Appendix A: Understanding the progress bar

springboardvr-cli push does a lot of work, most of it in parallel:

  • Signature of the previous build (if any) is downloaded
  • Files from the local directory/archive are scanned
  • Differences between the local (newer) & remote (older) build are
    • computed (by comparing hashes)
    • ...and compressed (with a fast preset)
    • ...and uploaded to SpringboardVR

In addition:

  • springboardvr-cli doesn't use any additional disk space while uploading
  • springboardvr-cli doesn't require a cache in-between uploads
    • You can upload from a different machine every time
  • springboardvr-cli tries really hard to use less than 256MB of RAM

By design, progress bar shown by springboardvr-cli push has two parts:

  • The half-tone bar shows the progress of scanning files & generating the patch
  • The full bar shows the progress of uploading the generated patch

Neither of these bars jump back. The half-tone bar may pause, waiting for the full bar bar to catch up: this means springboardvr-cli is waiting to send the patch data it has already generated before scanning more files, and it helps keeping memory usage reasonable.

The estimated time remaining is to be taken with a grain of salt, as are all ETAs.

results matching ""

    No results matching ""