Pushing builds with springboardvr-cli

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

springboardvr-cli push directory title:channel

Where:

• directory is what you want to upload. It can also be a .zip file.
• title is the project you're uploading (to get the name of your titles 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 mytitle titlename: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 mytitle titlename: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 mytitle

Where mytitle is the location of your title. 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 mytitle

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

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

springboardvr-cli fetch mytitle:channel destination

Where:

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

Now try to launch that title with;

springboardvr-cli launch title_folder mytitle:channel

Where:

• title_folder is the folder holding the newest install of the title,
• mytitle is the slug of the title to be launched, and
• channel is the channel of the title to be launched (windows!).

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

This launch will only work if title_folder contains the latest build for the given title 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.