go run skywire without cloning this repo

[0pcom]

Demo

If one has golang, git, bash and some other parsing utility (like awk) it's possible to run skywire without cloning the repo in the following way:

[user@linux]$  _commit="$(git ls-remote https://github.com/skycoin/skywire refs/heads/develop | awk '{print $1}')" ; GO111MODULE=on go run -ldflags="-X github.com/skycoin/skywire-utilities/pkg/buildinfo.version=v1.3.29 -X github.com/skycoin/skywire-utilities/pkg/buildinfo.date=$(date -u +"%Y-%m-%dT%H:%M:%SZ") -X github.com/skycoin/skywire-utilities/pkg/buildinfo.commit=${_commit} -X github.com/skycoin/skywire/pkg/visor.BuildTag=Linux" github.com/skycoin/skywire/cmd/skycoin-skywire@${_commit}

  ┌─┐┬┌─┬ ┬┬ ┬┬┬─┐┌─┐
  └─┐├┴┐└┬┘││││├┬┘├┤
  └─┘┴ ┴ ┴ └┴┘┴┴└─└─┘

 Available Commands:  
  visor     Skywire Visor  
  skycoin   skycoin daemon, cli, & newcoin  
  cli       Command Line Interface for skywire  
  svc       Skywire services  
  dmsg      DMSG services & utilities  
  app       skywire native applications        

Flags:
  -v, --version   version for skycoin-skywire

[user@linux]$ _commit="$(git ls-remote https://github.com/skycoin/skywire refs/heads/develop | awk '{print $1}')" ; GO111MODULE=on go run -ldflags="-X github.com/skycoin/skywire-utilities/pkg/buildinfo.version=v1.3.29 -X github.com/skycoin/skywire-utilities/pkg/buildinfo.date=$(date -u +"%Y-%m-%dT%H:%M:%SZ") -X github.com/skycoin/skywire-utilities/pkg/buildinfo.commit=${_commit} -X github.com/skycoin/skywire/pkg/visor.BuildTag=Linux" github.com/skycoin/skywire/cmd/skycoin-skywire@${_commit} -v
skycoin-skywire version v1.3.29

Known Issues

• the version must be manually specified. It should be possible to automatically version it
• dmsghttp-config is not currently supported when running skywire like this, but it could easily be supported (the dmsghttp-config is already embedded in /skywire.go at the repo root)

Suggested Actions

We should include a systemd service (and perhaps a script as well) for running skywire in this way, if it's possible to get the version to be automatically generated & compiled into the binary.

Deployment Strategy

The strategy for running skywire in this way should follow this general outline:

• generate a conf file for config gen (not a json config for the visor) at /etc/skywire.conf
• Generate & set secret key there
• specify that conf file as SKYENV=/etc/skywire.conf on config gen
• pipe the config from STDOUT of skywire cli to STDIN of the visor (using -n flags)

i.e. - a shorthand example

SKYENV=/ertc/skywire.conf skywire cli config gen -rn | skywire visor -n

Notes

• a working dir must be specified in the systemd service ; this will contain the local path where the visor will write any files at runtime
• The json config should be re-generated every time the service starts (it won't be written to disk when using -n flags)

Apps

It may not be possible to run apps unless the binary is compiled and placed in a known location. However, it should be possible to change the app location or command which starts the apps to os.Args[0] in order to use the compilation of skywire which is generated inside /tmp when skywire is executed with go run - in other words, to use the same binary as is already running.

Pros & Cons

Advantages

• the latest commits on develop will be used every time the visor is started or restarted
• no repository configuration or packages are needed
• the same setup (with the exception of the use of a systemd service) should work on all platforms

Disadvantages

• some issues mentioned above may need to be resolved for skywire to work robustly in this way
• This setup has not yet been thoroughly tested
• A recent enough version of golang may not be available for this to work on debian
• configuration may be less flexible when running in this way