Release workflow - building binaries automatically in github

[danielpodwysocki]

Recently I got back around to playing around with mgmt, it's becoming a bit cumbersome to copy over manual builds.

In particular, for cloud platforms I need to build on my own to drop the virt &augeas dependencies, so what's available on the release page doesn't work for me.
To ease adoption for people in the future, it'd be good if there was a binary out of the box for those and maybe RPM&apt packages.

Since I'm building those myself anyways, I'd be happy to contribute a github workflow at least the binaries on each tag. And maybe each commit to main as mgmt-unstable-<short sha> as well ?

Let me know if that sounds useful. If it does, some questions that pop into my head already:

1. should the default version be with or without libvirt?
2. should the default be with/without augeas?
3. should there be a no-augeas, no-libvirt version too? I strongly think so, so that users newer to Linux and unfamiliar with how building things works in the ecosystem can adopt the tooling without hassle.

[purpleidea]

We actually already built deb and rpm packages. They are roughly tracking git master. I push a new release everytime something casually more important lands, but if it's out of date for how you're using it, I can always be pinged to pop another rev.

https://dl.fedoraproject.org/pub/alt/purpleidea/mgmt/repo/master/

[purpleidea]

PS: If someone wants to make an "info box" kind of patch, I have one on my personal blog but haven't ported it to mgmtconfig.com yet.

Source for both on my github.

Eg:

[miekg]

I have a mac mini running (linux) BUT this only runs a forgejo runner and thus only works with that (as I've moved most things to codeberg.org).

But a simple cross compile with Go should work too, no?

[purpleidea]

But a simple cross compile with Go should work too, no?

I wish it would. If you are smart enough to fix it, we already even have the build targets. Look at the Makefile, you can build them, but they don't work for aarch64... I think b/c of libvirt-devel

[purpleidea]

(I gave up because I am dumb at compiler stuff like this.)

[miekg]

this is exactly why I like plain Go builds with nothing fancy, but I get the complexities for mgmt you need to operate in/around

[danielpodwysocki]

Oh, I didn't know that existed. Out of habit I went through the github release page and seeing the release from 2025 I figured I have to build my own 🤦

Might be a good idea to link it there?

[danielpodwysocki]

Hmm it also seems the way the deps are defined for Rocky / Fedora are not compatible - it requires libvirt-devel, but rocky only has libvirt resolvable through dnf.

No biggie for me, I can go to Fedora for what I'm trying. Might be relevant if first time users try to run it on RHEL&forks though.

[purpleidea]

It is mentioned in the guide but we definitely need to improve our docs game.

Unfortunately, can't support all distros ATM. At least not now. Would love to have packages for those too, but that will need a sponsor first.