Arch Linux package?

[BlackLight]

Arch Linux package?

[BlackLight]

I have proceeded to create and upload an AUR package in the meantime, so I can proceed and prepare a new release of Platypush with all the mandatory dependencies available on the AUR.

I've tested it on several of my machines and it seems to work.

Let me know if you folks want to take over it, or maybe integrate the release in your CI/CD pipelines.

[dairiki]

@BlackLight Thank you for your efforts!

I am a maintainer, but not the owner, of marshmallow_dataclass, so I speak only with tentative authority.
Also, I am not very familiar with Arch, AUR, or its packaging mechanics.

If you're willing to continue to maintain the AUR package, then I think that's great!

If it's straightforward to integrate the AUR packaging/release with our CI workflow, I'm all for it. Feel free to submit a PR for that. Also, feel free to reach out if I can help with that from this end.

[BlackLight]

Hi @dairiki, thanks for reaching back!

Maintaining a distribution package is relatively simple, but I proposed of integrating the process into the CI pipeline so I don't have to do it manually upon a new release.

The PKGBUILD format is quite straightforward, in the one I've uploaded basically you just need to update pkgver and the sha512sum of the package when there's a new release.

A PR that integrates it in Github Actions shouldn't be hard to put together, the only problem is that the process involves cloning the git repo of the package and pushing the changes with an SSH key that is allowed to modify the repo. So I guess that I either need a spare RSA pubkey that can be used in the CI process (and add it to the authorized keys for the repo), or use my own?

[dairiki]

@BlackLight Here's a GitHub action that purports to (I think) do what's needed: https://github.com/ulises-jeremias/github-actions-aur-publish
(There are quite a few similar actions listed in the marketplace — I picked the one with the most stars.)

As you say, these would involve generating a new SSH key pair for our CI to use to push the new releases. The new private key would be stored as one of our project secrets. (I don't think I have permission to set new secrets on the project, but I'm fairly sure @lovasoa would help to get that done.)

====

Another option that would avoid having to grant our CI push permission is to work up a script on your end that would pull the required information from GitHub's tags API. Or we could start making GitHub releases for each release and you could use GitHub's release API.

That script could either be run manually when there is a new release or it could be run periodically, polling for new releases.