feat(ci): Add Fedora RPM package build workflow #961
ginger
nex
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status/Blocked
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
To-Merge
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!961
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "tom/ci-fedora-rpm"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Following PR #950 which introduced the RPM spec and systemd unit files, this adds a comprehensive CI workflow for building, signing, testing, and publishing RPM packages. Includes GPG signing infrastructure with Ed25519 keys and automatic package registry deployment for stable, development, and feature branch builds.
Add documentation for RPM installation methods, repository configuration, and package management. Fix linting issues in spec file for pre-commit compliance.
7406556550d38c89f73ad38c89f73a809b6e4f3a809b6e4f3a98775d915c15662898a05a4627b8795a4627b8794b78ab39e04b78ab39e0ee2557f722@ -0,0 +81,4 @@# Aggressive GC since cache restores don't increment counterecho "CARGO_INCREMENTAL_GC_TRIGGER=5" >> $GITHUB_ENV- name: Install build dependenciesThis step of the workflow should happen after the srpm is generated, and use
dnf builddep <srpm path>to install the build dependencies listed in the specfile instead of duplicating them here.Agreed, fixed - thanks! 😄
@ -0,0 +282,4 @@rpm -qpl "$RPM"# Actually install it (would need --nodeps if dependencies aren't met)dnf install -y "$RPM" || rpm -ivh --nodeps "$RPM"Why does this silently try again with
--nodepsifdnf installfails? The workflow should fail if the dependencies fail to install.Made it a lot more faily now, thanks!
ee2557f7227be651a307@ -0,0 +85,4 @@run: |dnf install -y --setopt=keepcache=1 \wget \rpm-build \some (but not all?) of these tools are included in the
fedora-packagermetapackageI've actually got almost of them in the runner already, I just figured I'd explicitly list the packages we call to ensure they're always there just in case. I can remove a couple if you think that's pointless! 😄
I think I could only remove
rpm-buildandrpmdevtoolsbased on what I see indnf info fedora-packagerbut I've done that now! 🖖@ -0,0 +89,4 @@rpm-sign \rpmdevtools \rpkg \cargo-rpm-macros \cargo-rpm-macrosandsystemd-rpm-macrosdon't need to be installed here as they're already listed inBuildRequiresin the specfileDone, thanks!
7be651a307af53ea5599af53ea5599fbeb8b1f9efbeb8b1f9e82e3e95fd1@ginger does the latest RPM in the package registry validate? I'm really curious to know if Forgejo actually does sign them.
82e3e95fd1668919db4f@tcpipuk wrote in #961 (comment):
The latest RPM does not install, sadly.
dnfstates that it has no signature, which appears to be the case (note theSignaturefield):@tcpipuk Turns out that all that was needed was a magic query parameter! Packages are signed correctly now and dnf5 happily installs them.
ce6037712c2444b70d95Thank you very much!!
PR is likely to be superseded by a monolithic release workflow, keep open for now
2444b70d95d3f8da87dcd3f8da87dcf8fd03bd4bThis wants to be merged, just with a limit like this to avoid it running on every main/branch push:
I'll be coming back later with a refactor to integrate them to the main build pipeline, but it makes sense to add these package builds now with appropriate limits 🙂
f8fd03bd4b3c6f2d07e0