Currently, for building and deploying updates through continuous integration using volo, it's necessary to create a file under $HOME called .voloconfigfile containing the user GitHub token on the remote server before being able to call for volo install. (This is usually due the incapability of running interactive commands on a CI server, since there is no one to interact with).
I would be interesting that, in addition the .voloconfigfile, volo also read the Github token from an environment variable, eliminating the need for manually creating a JSON file, where volo would first search for .voloconfigfile and then fallback to VOLO_GITHUB_AUTH_TOKEN if the file is not located.
Currently, for building and deploying updates through continuous integration using volo, it's necessary to create a file under
$HOME
called.voloconfigfile
containing the user GitHub token on the remote server before being able to call forvolo install
. (This is usually due the incapability of running interactive commands on a CI server, since there is no one to interact with).I would be interesting that, in addition the
.voloconfigfile
, volo also read the Github token from an environment variable, eliminating the need for manually creating a JSON file, where volo would first search for.voloconfigfile
and then fallback toVOLO_GITHUB_AUTH_TOKEN
if the file is not located.For example:
General CI instructions file
By using the method above, automation becomes easier and feels more semantic than the following:
The use of environment variables would also permit users to switch between different Github accounts easily.