[CICD] Add RPM packaging support for RHEL/Rocky/OpenEuler#476
Open
shiptux wants to merge 17 commits into
Open
Conversation
xmhubj
reviewed
May 25, 2026
xmhubj
reviewed
May 25, 2026
Collaborator
|
Please rebase your code to pass CI tests |
xmhubj
reviewed
May 25, 2026
Add complete RPM packaging infrastructure: - RPM spec file with conditional backend builds (nvidia, metax, ascend) - Dockerfiles for NVIDIA (Rocky Linux 8) and Ascend (OpenEuler 24.03) - Parameterized build script (build-flagcx-rpm.sh) - GitHub Actions workflow for automated RPM builds - Proper SONAME and RPATH handling via patchelf - ASL 2.0 license identifier for RPM compliance
… backend
- Rewrite flagcx.spec to use %{backend} dynamic package names,
reducing 222 lines to ~90 lines and eliminating empty sub-packages
- Merge three per-backend Dockerfiles into unified Dockerfile.rpm
with BASE_IMAGE and BACKEND build args
- Add MetaX RPM support via Rocky Linux 8 + MACA SDK yum repo
- Extract version from spec via grep instead of hardcoding in Dockerfiles
- Add --network=host to docker build for DNS reliability
- Add PR-REVIEW-ISSUES.md for tracking remaining items
The Docker Buildx setup step was removed from the GitHub Actions workflow for building RPM packages. This suggests that the RPM build process no longer requires Docker Buildx capabilities, potentially simplifying the build environment or moving to a different build approach.
…split RHEL 9 spec path
… Makefile presence
…Os for libnccl floor and MetaX GPG
…rce0 fedora-style
…64); avoid producing arch-mislabeled rpm
shiptux
force-pushed
the
pr/rpm-packaging-clean
branch
from
a037781 to
aa8cc37
Compare
Upload built RPMs to flagos-yum-hosted from within the build-rpm job on the same self-hosted runner, gated on v* tags. h20 reaches the internal Nexus but not codeload/api.github.com reliably, so avoid the cross-workflow artifact round-trip that the deb upload-nexus flow depends on.
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Category
CICD
PR Types
New Features
PR Description
Adds RPM packaging support for FlagCX targeting RHEL / Rocky / OpenEuler
distributions, mirroring the existing Debian packaging path. Pair to
existing PR #393 (Ascend DEB) — this is the RPM-only sibling, freshly
rebased onto current
mainso the diff is reviewable.Background: original PR #394 has been open since 2026-02-26 with
no review and the branch has drifted 78 commits / 304 files behind
upstream main, making the diff unreadable. This PR is a clean replay
of the same packaging work (3 commits / 5 files) onto current main.
#394 can be closed in favor of this one, or the branch on #394 can be
force-pushed to match this clean state — at the reviewer's preference.
Produced binaries (built locally per backend):
For each of
nvidia/metax/ascend:libflagcx-<backend>-0.8.0-1.x86_64.rpm— runtime shared librarylibflagcx-<backend>-devel-0.8.0-1.x86_64.rpm— headers + .so symlink6 binary RPMs per release (3 backends × {runtime, -devel}), one
backend-specific docker image per build.
What changed (all under
packaging/rpm/, no DEB or source changes):rpm/specs/flagcx.spec— Parameterized spec using%{backend}macro to generate per-backend package names. Conditional sub-package
declaration; SONAME + RPATH handling via
patchelffor/usr/lib relocation.
rpm/dockerfiles/Dockerfile.rpm— Unified Dockerfile withBASE_IMAGE+BACKENDbuild args. Three backends share oneDockerfile, picking distinct vendor SDK base images:
rpm/build-flagcx-rpm.sh— Parameterized entry point:./packaging/rpm/build-flagcx-rpm.sh <backend>..github/workflows/build-rpm.yml— CI matrix building all threebackends on push and PR. Mirrors
build-deb.ymlfrom [CICD] add Ascend NPU backend support for Debian packages #393.How it was tested:
bash packaging/rpm/build-flagcx-rpm.sh nvidiaproduceslibflagcx-nvidia+libflagcx-nvidia-develRPMs cleanly in arockylinux:8 container. Same flow for metax / ascend with their
respective base images.
Companion DEB packaging (PR #393) and central distribution pipeline
(https://github.com/shiptux/flagos-packaging) are unaffected by this
PR — they were validated separately and continue to work.
Known limitations
Dockerfile.rpmforBACKEND=metax):gpgcheck=0. The MetaX upstream APT/YUM repo currently ships unsigned packages and does not publish a GPG public key; enablinggpgcheck=1would just fail. Documented inline as TODO; please flag in this review if a stable MetaX GPG key has appeared since.Requires: libnccl >= 2.10(group-call API minimum). FlagCX's NCCL adaptor may rely onncclConfig(2.14+) in some code paths but we have not confirmed; if you spot one, please ask us to bump.Dockerfile.metax-apt(RPM) is not part of this PR; the apt-based MetaX wheel-builder path lives in the siblingflagcx-packagingrepo and is tracked separately.