Improve architecture to: simplify codebase, serve private binaries, install-by-file-url

[jpillora]

I think the architecture should be changed from returning 1 complex shell script into 2 simple shell scripts:

curl <installer ip address>/myuser/myrepo

should return a simple script which fetches all of the OS information it can, and then repeats the call (Protocol + Host + path) except the call has extra fields added:

curl <installer ip address>/myuser/myrepo?os=linux&arch=arm64&tools=unzip,tar,gz

now that it has the minimum info (os arch tools) it can now do the checks in Go, and return a simple script which is effectively 1. curl to /tmp, 2. optional unpack, 3. chmod +x, 4. optionally mv to PATH. all the complex shell logic will move into go. second simple shell script does a minimal download and install. errors are just a one-liner echo "my error..."

subsequent improvements:

• uses trap to better cleanup and show errors
• for private installations, you can set a GH_TOKEN on your server and securely serve private binaries. this second script now knows exactly which file you need, and can get the presigned download URL: https://objects.githubusercontent.com/github-production-release-asset-2e65be/725845012/814abb0e-fc45-4965-be3b-24a0d6df38be?X-Amz-Algorithm=AWS4-HMAC-SHA256.....
  • this would not be feasible in the previous architecture as it would require installer to get the presigned URLs for all files, and there could be hundreds
• second script should also allow the user to provide the asset url directly url=https://github... to installer to skip the asset discovery step (api.github.com calls). this would essentially just do the final GET + unarchive + move into PATH steps.
• second script could support optional caching, through a Put / Get interface. which could support caching to disk, to s3, to artifactory, etc. user fetches URL x, and installer checks if x is cached, if not installer quickly downloads and caches it, and returns an installer download link instead of a GitHub content link

caveat:

• this may break a small portion of users who go via a dumb proxy. if user goes server-a.com -> installer.internal, and server-a changes the user's request setting Host: installer.internal then the second script would incorrectly have installer.internal when it should have server-a.com