Identify the right way of publishing rpm repos on openchami.org or similar and execute

[alexlovelltroy]

Goal

Publish OpenCHAMI RPM releases through a signed package repository that users can configure with DNF/YUM and consume without manually downloading GitHub release assets.

Current state

The release workflow builds and signs RPMs, verifies their signatures, and uploads them and their public keys to GitHub Releases. It does not generate repository metadata or publish a persistent DNF/YUM repository.

Work required

• Define the repository structure, including release channels, supported distributions and architectures, URL layout, retention policy, and whether SUSE/zypper compatibility is included.
• Establish a dedicated publication target for RPM content and repository metadata. Do not use the Hugo-managed website bucket, because website deployment may delete files outside the generated site.
• Configure the OpenCHAMI domain, CDN behavior, certificates, storage, access controls, and cache policies needed to serve the repository.
• Extend the release process to collect successfully built and verified RPMs before repository publication begins.
• Continue using OpenCHAMI/gpg-signing-manager as the signing source of truth.
• Generate repository metadata for the complete set of published RPMs and sign the repository metadata.
• Define how clients obtain, verify, install, and rotate the repository and ephemeral signing keys.
• Publish RPMs using immutable paths. Publish updated metadata only after all packages and metadata are available, with signed repomd.xml acting as the final publication point.
• Prevent concurrent release workflows from publishing conflicting repository states.
• Use GitHub OIDC and narrowly scoped AWS roles rather than long-lived cloud credentials.
• Define rollback and recovery procedures for interrupted publication, invalid metadata, signing failures, or CDN caching problems.
• Document repository configuration and installation instructions for users.
• Assign ongoing ownership for signing, release orchestration, reusable publication automation, and AWS/domain infrastructure.

Validation

Validate the published repository from clean supported systems:

• Repository configuration succeeds using documented instructions.
• Metadata and signing keys are retrieved from the public OpenCHAMI URL.
• DNF/YUM accepts the repository metadata and package signatures.
• A package can be installed and upgraded through the repository.
• Expired, untrusted, or incorrectly signed metadata and packages are rejected.
• A second publication updates available packages without corrupting the repository or exposing a partial state.
• CDN caching and invalidation behavior does not leave clients with incompatible package and metadata versions.

Completion criteria

• A documented repository URL is available under an OpenCHAMI-controlled domain.
• Release publication is automated and requires no manual copying of RPMs or metadata.
• Packages and repository metadata are signed and verifiable by clients.
• Publication is atomic, repeatable, and protected from concurrent writers.
• Installation and upgrade are verified on every supported platform.
• Operational ownership, key rotation, rollback, and troubleshooting procedures are documented.

Responsibility boundaries

• gpg-signing-manager: signing-key lifecycle and signing actions.
• github-actions: reusable repository-generation and safe publication mechanics.
• release: package aggregation, release policy, approvals, and publication orchestration.
• openchami.org: DNS, CDN, certificates, storage, and AWS infrastructure.