Open blacklight opened 1 year ago
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.
@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.
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?
@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.
I'm the creator and maintainer of Platypush, I have recently discovered this module and I love it so far!
After a bit of a learning curve to adapt to the new patterns, I've started migrating at least some of the existing vanilla Marshmallow schemas in my project to dataclasses - and life if much easier now that I have stuff like IDE autocompletion on objects rather than dicts.
The problem is that the Platypush package is on the AUR, and this module is not, so I'm holding back on adding the dependency on
marshmallow_dataclass
because otherwise I'd have to document the extra manual step of installing this package via pip.Is there interest in distributing
marshmallow_dataclass
on AUR as well? If there's enough traction I could also see this being merged in the officialcommunity
repo.I'm also happy to bootstrap a
PKGBUILD
and upload it to the AUR as a temporary unofficial maintainer if it's ok for you folks, since it's in my interest to get this on AUR ASAP, so I can merge and release my changes that use this module as an addition to the plain Marshmallow.