rpm generation - #565
rpm generation#565rccrdpccl wants to merge 8 commits into
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
mind moving from hack to scripts? so it's not included in the tarball. |
|
while we are here, should we also add a github workflow to build and publish the rpm? possibly similar to the tarball, as an OCI artifact in quay.io? or is there a better alternative? |
| --output="${WORK_DIR}/enclave-${VERSION}.tar.gz" \ | ||
| HEAD | ||
|
|
||
| # --- Step 2: Augment tarball for disconnected mode --- |
There was a problem hiding this comment.
I dont understand this. Why to have different tarballs for connected and disconnected?
We assume LZ is always connected, so embedding everything should not be needed
However, if we want to embed everything, we should always do it, dont we?
There was a problem hiding this comment.
I've assumed it would help, however it would generate a huge RPM (~500MB). hence I thought dual mode might help. in any case let's start without disconnected mode and we'll take it from there
| [ -f "${target}" ] || cp "${f}" "${target}" | ||
| done | ||
|
|
||
| %if "%{enclave_mode}" == "connected" |
There was a problem hiding this comment.
Should we do all this here or we just let bootstrap do it?
There was a problem hiding this comment.
you're right, probably bootstrap should do it
The LICENSE file contained MIT text, but pyproject.toml declared Apache-2.0. Apache-2.0 is the standard license for Red Hat's OpenShift ecosystem projects, providing explicit patent protection for enterprise use. Assisted-by: Claude Code <noreply@anthropic.com>
noarch RPM that installs enclave to /opt/enclave. Runtime dependencies mirror setup_env.sh. Post-install copies config examples to active names. No network activity during install — user runs 'make setup' afterward. Assisted-by: Claude Code <noreply@anthropic.com>
Creates source tarball via git archive, then runs Mock inside a Fedora 42 podman container targeting centos-stream-10-x86_64. Outputs RPMs, SRPM, and SHA256 checksums to out/. No host dependencies beyond podman. Assisted-by: Claude Code <noreply@anthropic.com>
Wraps hack/rpm/build-rpm.sh for building the enclave RPM. Uses Mock inside podman — only prerequisite is podman. Assisted-by: Claude Code <noreply@anthropic.com>
- Fix changelog date: July 7, 2026 is Tuesday, not Monday - Switch from Mock inside podman to rpmbuild inside CentOS Stream 10 container — Mock's nested chroot inside podman caused permission issues with bind mounts. The CentOS container provides equivalent isolation while building natively on the target platform. - Build produces both SRPM and binary RPM Tested: build, install, uninstall all pass on CentOS Stream 10. Assisted-by: Claude Code <noreply@anthropic.com>
0115f1a to
89a0564
Compare
I would just attach it to the release, definitely we'll add a github workflow to test/dry-run and publish - I'll add it before wrapping up, in the case we change approach during the review |
- Move RPM build files from hack/rpm/ to scripts/rpm/ so they are excluded from the release tarball (scripts/ is already in the tarball exclude list) - Add %license LICENSE and %doc README.md to the spec - Guard all %post and %postun scriptlet commands with || : for safety - Add rmdir cleanup in %postun to remove /opt/enclave on full uninstall - Remove stale hack/ exclusion from %install - Add GitHub Actions workflow (build-rpm.yml) that builds the RPM in a CentOS Stream 10 container on PRs/pushes and attaches to releases on tags Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Riccardo Piccoli <rpiccoli@redhat.com>
…nf fix - Use python3 tomllib for version extraction instead of fragile grep/sed - Add BuildRequires for tar and gzip (needed by %setup in minimal chroots) - Document the --define "enclave_version" requirement in the spec - Fix dnf install to use -q instead of suppressing all output including errors - Add comment about reviewing exclusion list when adding new repo directories Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Riccardo Piccoli <rpiccoli@redhat.com>
ShellCheck SC2034: SPEC_FILE was defined but never referenced. The spec file is accessed via the container volume mount instead. Assisted-by: Claude Code <noreply@anthropic.com>
This branch has not been deployed
3 participants
cc @javipolo @maorfr
we could build disconnected RPM (with uv dependencies cached within)) or connected.
This an example on how it would work, if we like the idea we can improve it further