Basic CI/CR

[m-242]

We need to test the auto-release, and it only runs on master.

[rfc2119]

Github Workflows looks pretty nice! I'll be reviewing this shortly, since I have some breaking changes on master right now

[rfc2119]

LGTM. I need to get some tests done before merging this

[rfc2119]

Ok, so I think we need to do a more testing setup rather than go test ./.... I've pushed some tests, and as you can see here in

sendall/cmd/transfer_test.go

Line 17 in 936bb09

serverTest = "http://127.0.0.1:8090/"

I run my tests against a local development server, since the service at transfer.sh is outdated. The needed steps to do before go test are as follows:

1. grab a binary release from the original repo (e.g latest)
2. change directory into the release location and issue:

transfer.sh --provider=local --listener :8090 --temp-path=/tmp/ --basedir=/tmp/

What do you think @m-242 ?

[m-242]

I like the idea of having a "real-life like" testing, but grabbing the binaries seems both costly and hard to setup properly.
I think that having a "request generating function" that we test on is much easier, and gets us faster testing. One big disadvantage is that we would have to update tests by hand according to transfer.sh and other file servers evolution.
On the other side, we don't need to test the standard libraries functions, and having tests relying on go test allows us not to care about things we cannot act on, and would be really hard to detect properly (what if the repo changes location ? what if github's release server is down while we test ? etc...).
Both these methods have problems, and I'm not too sure which is the most reliable/easiest to use.