github: ci: Add deployment

[patrickelectric]

No description provided.

[mbuesch]

Thanks for your PR. I much appreciate it.
However, I don't really want to do binary releases for any of my projects.

Doing binary releases adds special responsibility and workload that I can't really handle all by myself.
Adding a GH action to automatically build releases is one thing, but maintaining the released binaries adds huge responsibility and workload. Think of security bugs in crate dependencies.

Especially as Rust projects are almost trivial to build I don't think there's a big benefit for users as well.

I would rather like to keep the task of building and packaging to distributions and I would like to focus on source development and distribution instead.

[patrickelectric]

Thanks for your PR. I much appreciate it. However, I don't really want to do binary releases for any of my projects.

Doing binary releases adds special responsibility and workload that I can't really handle all by myself. Adding a GH action to automatically build releases is one thing, but maintaining the released binaries adds huge responsibility and workload. Think of security bugs in crate dependencies.

Especially as Rust projects are almost trivial to build I don't think there's a big benefit for users as well.

I would rather like to keep the task of building and packaging to distributions and I would like to focus on source development and distribution instead.

I fully respect your position. Maintaining released artifacts comes with some responsibility..

Still, speaking from experience across several open-source projects, having optional automated binaries can be a huge win for the community with CI doing the heavy lifting..

But to be clear, your boundaries are valid. Just sharing the perspective that binary releases can help users while keeping the maintenance overhead manageable and entirely opt-in.

To share my use case, I would like to have the binaries available to test it with my hardware, and I deal from a raspberry pi 0, some underground linux based SBCs and normal x86 machines. Imagine if I need to build this project every single time that I need it.. Imagine building in a raspberry pi 0, os taking care of cross compilation and rsyncing my way. Have the binary provided by CI is having the project a wget distance.

[mbuesch]

Thanks for sharing your use case.

Yes, I do understand that building Rust applications on underpowered hardware is a real pain.

Shouldn't we try to solve this problem on a higher level, instead of requiring all projects to provide pre-built binaries for all kinds of underpowered platforms?
Why can't cargo conveniently cross-build an application for arbitrary targets out of the box?

And if I were to provide pre-built binaries, then the Windows platform would certainly have to be part of it. I think there's the most benefit for users.

[patrickelectric]

Thanks for sharing your use case.

Yes, I do understand that building Rust applications on underpowered hardware is a real pain.

Shouldn't we try to solve this problem on a higher level, instead of requiring all projects to provide pre-built binaries for all kinds of underpowered platforms? Why can't cargo conveniently cross-build an application for arbitrary targets out of the box?

And if I were to provide pre-built binaries, then the Windows platform would certainly have to be part of it. I think there's the most benefit for users.

There is https://github.com/cargo-bins/cargo-binstall.. that'll work if there is github releases..

[patrickelectric]

And if I were to provide pre-built binaries, then the Windows platform would certainly have to be part of it. I think there's the most benefit for users.

I can add that, np

[patrickelectric]

@mbuesch Added windows deployment and template for macos, I can help with macos support later once my PR's get merged.

[patrickelectric]

Binaries available here for test: https://github.com/patrickelectric/disktest/actions/runs/19961973841

[patrickelectric]

ping @mbuesch

[mbuesch]

Thanks for adding that. I appreciate it.
But I think there was a misunderstanding here. I said if I were to provide pre-built binaries, then the Windows platform would....

As I said, I am not against binary distribution. Not at all.
I would really like to see this happen. But it will not be me. I simply cannot handle that.
I do binary releases for certain very carefully selected packages. But disktest is not really going to become one of them.

That said, I will support everybody who wants package disktest or any other app for distribution.
I am Ok with applying any change (CI or anything else) that is required for this or supports this, except for the final binary deployment step.

I am very sorry to have caused wasted time on your side.

[patrickelectric]

is it ok if I distribute via my repository ?

[mbuesch]

Yes, surely I would endorse that and I would welcome your work and your effort.

[midnight-wonderer]

Great work, both of you.
Binary releases help with accessibility, as not everyone is a developer or knows how to navigate cargo.

The project has great potential to be a better alternative for f3 use cases for consumers buying storage online.
I hope more people use this.

[mbuesch]

@midnight-wonderer Thanks for your comment.
One way to greatly improve user experience in general is to get software included in Linux distribution packaging.
I support everybody doing this.

[midnight-wonderer]

@mbuesch
I checked the process and kind of understand why not many people do the packaging. It is fairly cumbersome.
I am planning on working on a similar utility for a bit.

IMO, disktest diverges somewhat from what end users expect. My belief is that they don't even want to know how fast ChaCha20 runs. Just knowing that the algorithm is fast enough is enough.

To both of you on the thread, and everyone else who may stumble upon this.
I am looking for help with testing and README editing for other platforms, apart from Linux.
I also need help reviewing and improving the binary release workflow.
(For me, CI/CD is just for transparency; I do not plan on releasing frequently, as the utility is somewhat functionally stable.)

[mbuesch]

My belief is that they don't even want to know how fast ChaCha20 runs.
Just knowing that the algorithm is fast enough is enough.

Sure. I am 100% with you. This is true.

But I cannot answer this question.
I can't tell how many bytes per second would be fast enough for the user.
Therefore, I supply real world reference numbers.
The users have to decide if that is fast enough for their systems.

improving the binary release workflow.

I just want to say that putting a binary out there into the world is only part of the work required.
It also has to be monitored for problems in the whole dependency chain and actions have to be taken, even if the project's source code is not affected because the problem is in a dependency.

And I really don't see the fundamental difference between whatever install disktest and cargo install disktest. Yes, a rust toolchain has to be installed, but that's just one rustup-init call away from success.

I see a benefit in distributions packaging software as an orchestrated operating system. But single binary distributios... not that much.

[midnight-wonderer]

You might already be aware of this, but many people use tools like bin and mise to manage binary installations.

FYI, just in case.

[mbuesch]

I do not see how that is easier than cargo install .... Yes, it's a bit faster. But that's basically it. What's the real actual value of these kinds of binary distributions for Open Source programs? Users not wanting to learn how to type cargo install ... is not convincing :)

[midnight-wonderer]

How do you update the software after cargo install?
Is the method similar to apt upgrade?

My point is that by putting the binary on cargo, you are publishing it to the Rust market.
Putting it on GitHub is similar to publishing it to a market where people can manage it along with all their other binaries.
They can install, update, and remove it with the same tools they already use.

It is also worth noting that these tools work with AppImage. This is part of the reason why Obsidian, despite not being an open-source project, publishes on GitHub too.

[mbuesch]

How do you update the software after cargo install?

By running the same cargo install command again.

I see that there are some IMO small benefits of distributing binaries.
But these benefits do not outweigh my time required do do this.

As I said, I am not against doing binary releases.
I'd just like somebody else to do it. That's perfectly fine then.

Thanks for explaining your view.