ci: add to scaffold a GH action to build chain's binary on release about cli

[fadeev]

@marbar3778 And having this for Starport itself can be a huge help. Initially, even without the headless stuff #28

Having CI that runs on each PR will help us make sure that we didn't break anythig.

starport app github.com/example/blog
starport type post title body
starport serve

It's a bit harder to do with a long-running process like serve. I've tried blogd start --halt-height 10, but it always returns an. error code. Would be cool if it returned success on this forced halt, so we could differentiate between blogd start didn't work and blogd start successfuly halted after ten blocks.

[ilgooz]

I think it is best to create a starport action for GH and use it to build the cross platform binaries with the build command (requires some tweaks on the build command) and use another action to release the binaries.

Because we need to set some build time variables while building the app which includes things like chain id and this could have been configured inside the config.yml. Otherwise without using starport, we need to scaffold a custom script to figure out and set these variables.

wdyt?

[fadeev]

Do you mean an action for linting? I can see that being useful.

[tac0turtle]

linting, test (but commented out for now), go releaser and docker deployment configuration. I can help out on a few of these

[fadeev]

Functional testing is a big one, and actually can be considered a high priority. Having an action that runs starport serve on PR, checks that there are no errors, checks 26657 and 1317, would be an incredible value add ⚡️

[faddat]

This is a great idea.

I am experimenting with similar stuff over here:

https://gitlab.com/virgohardware/hardware/-/blob/master/.gitlab-ci.yml

https://gitlab.com/virgohardware/hardware/-/jobs/663817054

I have not really tried GitHub actions yet, and I like that GitLab the platform is an open source project itself, but I'd probably give GitHub actions a whirl if we templated actions.

Also, you can do long-running processes on GitLab, that'll be added to that repo soon.

[faddat]

gaiad has a testnet command which launches 4 containers and gets a small testnet rolling, and could be useful here.

More super-interesting:

as starport matures, people with starport devices may be able to allow devs to launch testnets across their fleet of devices-- either for a fee or for free.

These "real world" testnest would be quite valuable, because they would include the types of network issues only seen in an actual live network.

[faddat]

#236 closes this

[fadeev]

This is still very much relevant. We need a good default set of GH actions for scaffolded chains. Releasing a binary on GH release is my favorite, personally, so that users will be able to curl https://get.starport.network/foo/chain | bash to install a binary of the chain.

[fadeev]

As part of this issue, let's remove everything that's currently in .github/workflows and add a workflow that builds a chain and releases a binary, probably with the help of go releaser.

[fadeev]

Sounds like a plan, @ilgooz! 👍 This actually plays well into our goal of making starport build more flexible.

[fadeev]

I think one of the goals with this is to make sure our release system is compatible with curl | bash way of installing the binary.