search

oll3 / bita

Differential file synchronization over http
https://crates.io/crates/bita
MIT License
265 stars 10 forks source link

Automatically build & publish binary releases #25

Closed MCOfficer closed 2 years ago

MCOfficer commented 2 years ago

Closes #24

Mac support should be trivial in terms of this workflow, but it fails to compile due to some std::os::linux imports.

Test run (commit): https://github.com/MCOfficer/bita/actions/runs/2156708932 Test run (release): https://github.com/MCOfficer/bita/actions/runs/2156697767 Test release: https://github.com/MCOfficer/bita/releases/tag/binary-test2

Windows binary was tested on my machine; Linux binary in my WSL; musl binary in a clean alpine container.

oll3 commented 2 years ago

Closes #24

* Runs on every push (commit & tag)

* Build bita for windows, linux and linux(musl)

  * Windows build uses a statically linked C runtime to prevent runtime errors
  * musl uses the rustls feature to be as compatible as possible
  * *nix binaries are stripped of debug symbols to save filesize

* binaries are published to the workflow so contributors/testers can download them directly

* When on a tag, creates a release (if necessary) and uploads the binaries there

Mac support should be trivial in terms of this workflow, but it fails to compile due to some std::os::linux imports.

Test run (commit): https://github.com/MCOfficer/bita/actions/runs/2150942533 Test run (release): https://github.com/MCOfficer/bita/actions/runs/2150994973 Test release: https://github.com/MCOfficer/bita/releases/tag/binary-test

Windows binary was tested on my machine; Linux binary in my WSL; musl binary in a clean alpine container.

Looks great and well done with adding the different targets! :star2:

A couple of thoughts... Do you think it would it make sense to add version (from tag for release-artifacts, like bita-v0.9.0-x86_64-unknown-linux-gnu) and possibly short git-revision or branch name to workflow artifact file names? Might make sense to archive+compress artifacts too, to simplify future releases with multiple binaries/files per target (shell completion files, change log or whatever it might be).

MCOfficer commented 2 years ago

Do you think it would it make sense to add version (from tag for release-artifacts, like bita-v0.9.0-x86_64-unknown-linux-gnu) and possibly short git-revision or branch name to workflow artifact file names?

I'm fairly indifferent about it. I guess it makes sense and it's a simple thing to change, so if you want we can do that.

Might make sense to archive+compress artifacts too, to simplify future releases with multiple binaries/files per target (shell completion files, change log or whatever it might be).

Also helps with preserving binary flags. The big downside is that it fractures the workflow since you have to use tar on linux and zip on windows. Personally I'd hold off on that until it's needed.

oll3 commented 2 years ago

Do you think it would it make sense to add version (from tag for release-artifacts, like bita-v0.9.0-x86_64-unknown-linux-gnu) and possibly short git-revision or branch name to workflow artifact file names?

I'm fairly indifferent about it. I guess it makes sense and it's a simple thing to change, so if you want we can do that.

At least for releases I think it would look good. So if you don't mind then please do.

Also helps with preserving binary flags. The big downside is that it fractures the workflow since you have to use tar on linux and zip on windows. Personally I'd hold off on that until it's needed.

Maybe could use zip for all but not sure it preserves file permissions. So fair enough, lets not create archives for now.

Could you also squash your commits into a single, descriptive commit?

Thanks!

oll3 commented 2 years ago

Much appreciated @MCOfficer , thank you!