Skip to content

Add RPM spec file and CI workflow for RPM publishing#4

Open
netmindz wants to merge 10 commits into
appliedapp:mainfrom
netmindz:rpm-publish
Open

Add RPM spec file and CI workflow for RPM publishing#4
netmindz wants to merge 10 commits into
appliedapp:mainfrom
netmindz:rpm-publish

Conversation

@netmindz

@netmindz netmindz commented May 2, 2026

Copy link
Copy Markdown

This pull request significantly refactors and expands the project's CI/CD workflows to support reusable build steps, cross-platform packaging, and automated RPM repository publication for Fedora. The changes modularize the build process, introduce a Fedora RPM spec, and streamline release artifact handling.

Workflow modularization and improvements:

  • Introduced a reusable build workflow (.github/workflows/build.yml) that runs formatting, linting, testing, and builds release binaries for both native and cross targets, with optional artifact uploads for use in CI and releases.
  • Refactored the main CI workflow (ci.yml) to delegate all build and test steps to the new reusable build workflow, simplifying the file and removing redundant job definitions.

Release and packaging enhancements:

  • Overhauled the release workflow (release.yml) to:
    • Use the reusable build workflow for artifact generation.
    • Add concurrency controls to prevent overlapping releases.
    • Automate artifact collection and attach binaries and .deb packages to GitHub Releases.
    • Add a comprehensive Fedora RPM build and packaging matrix, supporting both x86_64 and aarch64 architectures, including SRPM and binary RPM creation using Fedora containers and mock.
    • Implement a job to publish RPMs to a GitHub Pages-hosted Fedora repository, complete with metadata, a .repo file, and a landing page for easy consumption by users.

Fedora packaging support:

  • Added a new rusty_lights.spec file for Fedora RPM packaging, including build requirements, install instructions, systemd integration, and documentation/license handling.

These changes make the build, test, and release process more maintainable, enable easy cross-distribution packaging, and provide users with direct access to RPM packages via a public repository.

Most important changes:

Workflow modularization

  • Added .github/workflows/build.yml as a reusable workflow for building, testing, and packaging across native and cross targets, with optional artifact uploads.
  • Updated .github/workflows/ci.yml to use the new reusable build workflow, removing all previous job definitions.

Release and RPM packaging

  • Refactored .github/workflows/release.yml to use the reusable build workflow, automate artifact handling, add concurrency, and introduce a full Fedora RPM build/publish pipeline, including GitHub Pages RPM repo publication.

Fedora support

  • Added rusty_lights.spec for Fedora RPM packaging, including build/install scripts, dependencies, and changelog.

netmindz added 10 commits May 2, 2026 11:12
Remove main branch restrictions for push and pull request events.
- Use ubuntu-24.04-arm runners for native aarch64 mock builds
- Pin mock results to /tmp/mock-result so paths are deterministic
- Per-arch artifact names (rpms-<arch>, mock-logs-<arch>)
- publish-rpm-repo merges all rpms-* artifacts, deriving dist/version
  from RPM filenames and deduping shared SRPMs
@rlfnb

rlfnb commented May 4, 2026

Copy link
Copy Markdown
Contributor

Thanks for putting work into this - RPM support is welcome.
The current .deb packaging is intentionally minimal: a single cargo-deb step in CI that publishes the artifact to GitHub Releases. To keep things symmetric and easy to maintain, we'd like the RPM side to mirror that exactly - a cargo-generate-rpm step in the same release workflow, output uploaded next to the .deb. Both architectures (x86_64 and aarch64) would be great.
Hosted DNF repositories, mock builds in Fedora containers, and the CI refactoring in #4 are interesting but a much bigger scope than what we have on the Debian side. Let's keep those out of the initial RPM PR so it stays reviewable and the two distro paths stay balanced.
Would you be up for reworking #4 along those lines? Happy to close #2 in the meantime since #4 supersedes it.

@rlfnb rlfnb mentioned this pull request May 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants