building binaries for release

Criomby commented 5 months ago

There are no binaries available for this project and the issue is mentioned in the readme so I thought I'd open this issue.

Since I have some experience cross-compiling locally, but not much experience with GitHub Actions, I put the following workflow together in this PR: #10

Open topics:

[x] Workflow is triggered on a new release (created)
[x] Assets automatically uploaded to release which triggered it
[x] Checksums are also generated and uploaded to release
[x] This uses the Action actions-rust-cross which does some good stuff (see the part on downloading cross binary instead of building it during workflow runtime) but since I'm not fluent in Perl I couldn't wrap my head around everything that's happening but I guess it works pretty well
[x] Apple Silicon runners are only available with paid tiers (will be cross-compiled)

Criomby commented 5 months ago

I just tested everything from #10 and it works the way it should.

Binaries for Apple Silicon are cross-built from x86 macOS. Checksums are generated and uploaded with the respective archive as an artifact.

Now the last points are to also automatically draft a release with the creation of a new tag and upload the artifacts to it and also whether the release is triggered manually or with the creation of a new tag.

talwat commented 5 months ago

Are binaries also cross compiled for every other architecture?

Criomby commented 5 months ago

Binaries are built for the following architectures/OS:

Linux-x86_64
Linux-aarch64
Windows-x86_64
macOS-x86_64
macOS-aarch64

The binaries are built on their native architecture, except the binaries for *-aarch64 which are cross-compiled as the GitHub runners are x86 architecture.

I think these are enough architectures to support the vast majority of consumer machines. Windows ARM is pretty much non-existent and somebody still using 32-bit Linux can probably compile themselves.

talwat commented 5 months ago

Is it possible to also cross compile them for the other ones so there's just one runner? It's easier to manage & uses less resources.

Criomby commented 5 months ago

I don't necessarily agree with that:

Since every build is running in its own container you have an easily reusable and reproducible sequence of commands shared by all runners. This makes managing, testing and debugging way easier and it clearly indicates in the actions which build fails and the errors are logged with it. Therefore, you can also enable notifications which then directly state which build fails if there are any issues down the line.

The overhead of these containers is very small and since they run in parallel, it significantly reduces the runtime of the workflow in total in comparison with sequential execution. You just have an additional runner per architecture/OS running which in my opinion is negligible regarding resource usage and they are free for public repos.

Additionally, you'd also have to use cross to cross-compile for every other architecture/OS than the native one of the runner (e.g. assume your runner usesubuntu-latest on x86). I don't know how that will affect the build times in comparison with direct cargo building since cross essentially uses another container on top to create the build environment. So by using just one runner you will end up using 2 containers less but with significantly longer execution times.

talwat commented 4 months ago

So then is there a separate runner for the cross compiler? I feel like that would just make sense considering your reasoning for keeping the runners separate.

Criomby commented 4 months ago

Yes, there is a separate runner for each cross-compiled target. See the PR, every specified target in the workflow that is not x86_64 will be cross-compiled.

Also I suggest you read the cross documentation to better understand what happens behind the scenes when using it to build binaries instead of cargo.

Criomby commented 4 months ago

Anyways, I'm not sure what you think is wrong with this but the workflow runs in my fork so for anybody interested you can get the binaries HERE

talwat commented 4 months ago

I'm just waiting for the release part of the workflow, but if you'd like I can finish that part myself.

talwat commented 4 months ago

Thanks for the help though :^) This is my first time hearing about cross so I'll probably just copy the workflow file here for my future projects to provide binaries.

Sorry for the slow updates, I'm a bit busy with school at the moment so that's why I can't respond as quickly.

Criomby commented 4 months ago

Ahh ok my bad, since we haven't discussed this I thought there was something else...

No worries, I implemented the release assets upload and now everything works the way it should (see above, I updated the to-do descriptions).

Therefore, PR #10 is now ready to be merged.

Happy to help. if there's anything else, just contact me :)

talwat commented 4 months ago

When I made a new release, it compiled fine but got stuck when it was time to upload. There was this error on the workflow runner:

HTTP 403: Resource not accessible by integration (https://uploads.github.com/repos/talwat/pokeget-rs/releases/147298247/assets?label=&name=pokeget-Linux-x86_64.tar.gz.sha256)

This seems really odd. Any idea why this might be happening?

talwat commented 4 months ago

Update: I figured it out, I just needed to edit the permissions of the token.

Should be good to go then, thank you so much for contributing and being patient! I apologize for all the delays...

talwat / pokeget-rs

building binaries for release #9