feat: add AUR publishing capabilities

[mautamu]

Description

Adds the capability to publish crate updates to the AUR. Although I am reasonably confident in this build, I'm not certain it's finished. Additionally, we will need to add the secrets to GitHub to finalize this change and add leftbot to the AUR repos.

Type of change

• Development change (no change visible to user)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation only update (no change to the factual codebase)
• This change requires a documentation update

Checklist:

• Ran make test-full locally with no errors or warnings reported
  Note: To fully reproduce CI checks, you will need to run make test-full-nix. Usually, this is not necessary. [N/A]

[VuiMuich]

Plus we need @leftbot added as comaintainer on all of the AUR packages. Afaik only @lex148 has permision to add new maintainers.

[Eskaan]

Is there a way to move the systemd/non-systemd part to the build function? I don’t really like to see it build twice every time.

[hertg]

@mautamu If you want to see a reference workflow for automatic AUR releases, I implemented that in another project of mine. It looks like you are coming to a very similar solution.

https://github.com/hertg/lightdm-neon/blob/main/.github/workflows/aur-release.yml

https://github.com/hertg/lightdm-neon/blob/99724786c5ad1e73cac762dc1ce4016e9c263bca/.github/workflows/release.yml#L29-L38

https://github.com/hertg/lightdm-neon/blob/main/.ci/generate-pkgbuild.sh

[mautamu]

@hertg Would like your thoughts on this as part of #1258 as well. This may be something that we'd reject depending on the strategy there.

[Eskaan]

Referencing my review above

Is there a way to move the systemd/non-systemd part to the build function? I don’t really like to see it build twice every time.

I don't really know all about the PKGBUILDs build functions, but could you create a non-systemd build function instead so it doesn't build twice?

[hertg]

@hertg Would like your thoughts on this as part of #1258 as well. This may be something that we'd reject depending on the strategy there.

Not sure how you mean? Generally, I think it would be a good idea to publish things via CI, because then the exact publishing process is "documented" since it was scripted out, and the publishing itself is quite transparent, since it happens via a workflow that can be audited by users. When it comes to signing, I'm not sure how we should handle that. I'm not really experienced myself when it comes to that, and we should probably check out how other projects handle it. (I am also a bit out of the loop when it comes to building leftwm, with all the syslog and systemd feature flags...)

Should some of the core devs sign releases manually? How could we do that, and still keep the release process as simple and transparent as possible? Should leftbot be able to sign stuff? If so, how do we protect that private key, and how would we know if it was compromised? I don't have the answers to those questions and it would be great if we could collect some resources / case studies on how other (large) foss projects do this... Maybe it would be possible to trust the keys of a few core devs, let them update and sign the leftbot key every few months or so, and then leftbot can sign releases by itself? I have to look more into PGP signing to figure out if that even makes sense.

---

There's also another discussion to be had, which CI we want to use. You mentioned that you'd like to use codeberg more, and I feel the same way. I already sponsor them via liberapay, but I'm also thinking about joining their association. They also offer CI capabilities, which I think we'd need to apply for first. But all this (codeberg / github) seems like another meta discussion, that we probably should move to a separate thread.