amplify-edge / main

main code
Apache License 2.0
3 stars 7 forks source link

Booty Epic #108

Open joe-getcouragenow opened 3 years ago

joe-getcouragenow commented 3 years ago

CI, CD and provisioning

  1. Get Binaries for Dev and User. Puts them all in right location for dev and CI.
  2. Git tools for dev and tagging / releasing
  3. Github CI and local CI are identical !!
    • github action adaption: The current working one, just installs booty to the OS, and then calls the make file.
    • makefile adaptation: Each repo still has a makefile, but that make files can call booty to do dep and then use the binaries installed.

Where

Do the work in shared repo , and expose in booty.

Shared repo can even have the Cmd if you want. Booty can just import the Cmd from its root.go down.

CLi and Server might need to use a few imports from shared too like the bs-crypt for decoding the encrypted config.

Elements

cmd framework CLi framework we use is Cobra remember.. ) Make it a Cobra Cmd so the other Cmd's of booty, Cli and Server can import it.

**versioning

Need binaries versioned. Need golang tool to automate git tag / release

**cross build

Local or in ci. No need for github action i found. https://github.com/goreleaser/goreleaser

push github releaser

https://github.com/github-release/github-release

https://github.com/tcnksm/ghr

download github release

https://github.com/goreleaser/godownloader

binary updater

All binaries must self update so that when a new release happens they update.

https://github.com/mouuff/go-rocket-update

Where to look for updates ?

Behaviour ?

Suggest you reuse https://github.com/hashicorp/go-getter for having the ability to get a release from anywhere. Its easy to adapt it to download from google storage for example. It supports a wide range of sources including github url, fileserver path, or even just the path to a local directory. See https://github.com/hashicorp/go-getter#url-format for more information on all supported input types.

Desktop apps later will also need to self update.. But we worry about that much later.

Get binaries

Booty needs to get binaries for a developer and a user.

User and Dev will want slightly different binaries and tools to be installed, and we don't want to confuse a user with too many binaries. So, a Cmd named "InstallDevBinaries" and "installUserBinaries" should work. You should add a "delete" and "list" equivalent for them too.

The name of the binary installed varies by GOOS and GOARCH, and the make file needs a mapping to them, so make sure the GOOS and GOARCH matrix of the binary is resolvable, so the make file can call it no matter what GOOS / GOARCH it is.

Use this to install them. See the CMD entry point.. https://github.com/ncabatoff/yurt/blob/master/binaries/binaries.go It uses the excellent https://github.com/hashicorp/go-getter under the hood. example: https://github.com/nocalhost/nocalhost/blob/main/internal/nhctl/syncthing/syncthingInstaller.go

getting our releases to users

We have a russian doll scenario in that we can ask users just to install booty and then booty does everything else.

Once booty self updating works, we can use gofish to handle all the binaries we build. However, it seems gofish can update itself, so you can maybe make booty self updating using gofish itself !! https://github.com/fishworks/fish-food/blob/main/Food/gofish.lua

I wrote all this before here: https://github.com/getcouragenow/core-fish/blob/master/multibuild.go It will do pretty much everything we need and talks to git and gofish.

SO a cmd "user install" would pull the binaries that we released liek server and CLI.

GO fish below has the advantage of having alot of tooling already done and is fully cross platform. It can also handle the self updating stuff. a user just calls "fish update" and from the remote manifest gets whatever is needed. Because we would include gofish inside booty, we get all those goodies.

There is also another way: https://github.com/fishworks/gofish

Google Cloud deploy

We can probably support it now if we want to.

As far as User-walkthrough docs this is well written and will save use tons of time: https://github.com/cdr/code-server/blob/master/doc/guide.md. We can copy that and adapt it in the docs.

mkcert As the code-server docs suggest user need a SSL for local testing when NOT running under caddy. https://github.com/FiloSottile/mkcert Am not sure if we have it in out tools folder and embedded as a cmd for booty, but we prob should and its super easy to do.

here is the reference to mkcert in their docs: https://github.com/cdr/code-server/blob/master/doc/guide.md#self-signed-certificate, so you can see why its used.

Install script

Want user to be able to run it from anywhere. Google server, hertzenr, desktop. This one is really well done and battle tested: https://github.com/cdr/code-server/blob/master/install.sh. Lets revisit ours and use theirs i suggest.