Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build debian package with github actions #1441

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

catango
Copy link

@catango catango commented Jan 12, 2025

Build debian package for architectures amd64, armhf and arm64 with github actions. Default build settings are used and linked against libraries of the respective debian version. New github action build-rust-deb-action is used that leverages cargo-deb in a dockerized environment.

@catango
Copy link
Author

catango commented Jan 12, 2025

Some tests fail, as cross build breaks with bindgen 0.71. This is considered in the custom workflow in the pull request that builds with bindgen 0.70.1

Build debian package for architectures amd64, armhf and arm64 with
github actions. Default build settings are used and linked against
libraries of the respective debian version. New github action
build-rust-deb-action is used that leverages cargo-deb in a dockerized
environment.
@kingosticks
Copy link
Contributor

It's a bit weird that we already have workflows to build binaries for various platforms, but rather than use those, this adds another entirely ortholognal way to build. And we already have the first problem with doing it this different way. It would be nicer if we could leverage our existing build stuff and package those up instead. Is there some benefit to doing it this other way that I'm missing?

@photovoltex
Copy link
Member

Is there even a need to upload any artifacts that are built in the ci? I would have thought that our CI was primarily used to test the integrity of the library and not to build usable binaries/packages.

But it might be that I just assumed that.

@kingosticks
Copy link
Contributor

@photovoltex I don't believe there's much value in uploading the results of normal CI builds. If we were just packaging up the results of our existing builds, then it basically comes for free, so we could do that. But if it adds any extra time to the CI loop, or extra effort to maintain, then I don't see the point.

There is value in providing binaries and packages for our releases. Although we'd have to decide exactly which combination of features to provide and document that clearly.

@photovoltex
Copy link
Member

Okay, thanks for the clearup^^

@catango
Copy link
Author

catango commented Jan 14, 2025

I have provided this workflow to build a clean dedicated debian package, build with debian stable. The current test workflow builds on what is currently provided by the Github actions default image (what is currently some Ubuntu). This may change any time. To have a build in a reproducable environment, we may have to build e.g. inside an extra container, running inside the default image - and this is what I have added here (encapsulated into a dedicated Github action for simplicity).
Anyway, if no deb files shall be released, this action obviously does not make much sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants