GitHub actions CI/CD releases

[praveenperera]

Adds CI and CD using GitHub releases. Closes #6

Will create a new release when a new v* tag is pushed. You can see it here:

https://github.com/praveenperera/bore/tree/github-actions-ci-cd

[ekzhang]

Wow, thanks for the contribution! This is great. Let me take a look and get back to you on this. There's almost as many lines of code in CI as there are for the rest of the Rust codebase. :')

This is based on https://github.com/japaric/trust, right?

[praveenperera]

Yup! Its based on trust and https://github.com/XAMPPRocky/mean-bean-ci-template

I'm also using it in:

• https://github.com/cantino/mcfly
• https://github.com/avencera/rustywind

[ekzhang]

Read through the scripts, looks good to me. I'm a little bit cautious about recommending that people pipe a bash script downloaded from the internet to sudo sh, but I can't think of any better solution than this.

I'll try running CI on your branch, update the README a bit (there's a new "installation" section to update now), and if all looks good will merge.

[ekzhang]

That's a lot of CI runs! I'm glad GitHub Actions is free for public repositories. :')

[ekzhang]

Hm, I think Windows is missing from the CI and deploy steps! Right now it's only building for Linux and macOS.

Also bore only needs to be compiled on stable, we don't support beta or nightly.

[praveenperera]

@ekzhang Added windows and removed beta and nightly

[praveenperera]

@ekzhang looks like a test is failing on windows: https://github.com/praveenperera/bore/runs/5983694419?check_suite_focus=true

[ekzhang]

Ah, I see, guess the tests don't work on Windows. The problem is likely TcpListener::bind("localhost:0"). I'm surprised that this was never an issue for anyone though.

[ekzhang]

Going to release 0.3.0 for now since there's a few pending features, but I'll try to debug the Windows problem as soon as I get the chance.

[ekzhang]

This looks fantastic! The build looks like it works perfectly and the binaries appear to work as well. Do you think it's okay if we remove install.sh though? There's a couple concerns I have:

1. People on non-Unix environments will get errors if they try to move things to /usr/local/bin. They also might not necessarily have bash or curl installed.
2. Asking people to curl ... | sudo sh -s something from a GitHub URL is somewhat scary and can open up supply chain attack vectors.

I could add something like this in README.md:

---

# Installation (requires Rust, see alternatives below)
cargo install bore-cli

# On your local machine
bore local 8000 --to bore.pub

(... then, further down)

Installation

The easiest way to install bore is from prebuilt binaries. These are available on the releases page for macOS, Windows, and Linux. Just unzip the appropriate file for your platform and move the bore executable into a folder on your PATH.

You also can build bore from source using Cargo, the Rust package manager. This command installs the bore binary at a user-accessible path.

cargo install bore-cli

---

[praveenperera]

Hey @ekzhang, I personally don't think that sudo install scripts are scary. But both sides have been discussed a lot in other forums. But basically comes down to people are comfortable with package managers, and the bash script is not any more safe or dangerous than a package manager. Also anyone that is afraid can look at the install script right in the repo before installing. It's not too big or complicated.

That being said I understand the fear, and this is your repo, I have removed it.

And I agree the script not working for Windows isn't great. I don't have a solution for that, I haven't used Windows in a while. Do most people use the linux subsystem?

[ekzhang]

Thanks for understanding! I appreciate your thoughts on this. It's definitely true that install scripts aren't necessarily more dangerous than a package manager, and the install.sh script here is definitely simple to inspect. The Windows issue is perhaps more difficult to resolve though.

Perhaps I could try to set up a quick local brew tap (#27) after this so that most people using macOS could install the binary with one command. That way at least (probably?) most users would still a one-click binary install. :)