Adding publish-rpm-repository action/workflow

[alexlovelltroy]

Description

This pull request introduces a new reusable GitHub Action and workflow for securely publishing RPM repositories to S3, including robust documentation and CI enhancements. The main focus is on enabling safe, verifiable, and automated publication of signed RPM packages, with strong key management and metadata integrity guarantees. The changes add both the action implementation and comprehensive usage documentation, as well as integration into the CI pipeline for testing.

New RPM Repository Publication Action and Workflow

Major new features and documentation:

1. New reusable workflow and action for RPM repository publication

• Adds .github/workflows/publish-rpm-repository.yml and actions/publish-rpm-repository/action.yml to aggregate signed RPMs, generate and sign repository metadata, and publish to S3 with optional CloudFront invalidation. This includes concurrency controls, robust key handling, and a safe publication order to ensure metadata integrity. [1] [2]

2. Comprehensive documentation for the new publication process

• Documents the action and workflow in README.md and a dedicated actions/publish-rpm-repository/README.md, covering publication model, security, inputs/outputs, and client trust configuration. Usage examples and security best practices are included. [1] [2] [3] [4]

3. CI/CD and linting enhancements

• Updates .github/workflows/ci.yml to add a test-rpm-repository-publisher job that exercises the new publisher inside a container, and adds a new .github/actionlint.yaml to suppress false positives for workflow-specific properties. [1] [2]

4. Security and compliance

• All new files include SPDX copyright and license headers, ensuring compliance and traceability. [1] [2] [3] [4]

5. README enhancements and cross-linking

• Updates action and workflow listings in README.md for discoverability, and adds cross-references between documentation files for easier navigation. [1] [2] [3]

These changes collectively provide a robust, auditable, and easy-to-use solution for publishing signed RPM repositories in a secure and automated fashion, with clear guidance for both direct and workflow-based usage.

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• I have updated the relevant documentation (CLI examples, man pages, README, other docs, etc.)
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Dependency update

---

For more info, see Contributing Guidelines.

[seantronsen]

Overall this seems fine to me. Were you able to test it against one of our existing repos (example: I used metadata-service when testing the gpg signing workflows)?

Aside from that, I only came across some nitpicks and out-of-scope ideas for future edits. All optional.

[seantronsen]

nitpick: it's a bit jarring for both the workflow and the action to have the same name.

[seantronsen]

Reminder for @seantronsen

We might want to create a github issue that focuses on standardizing varnames + usage across the recently created workflows + actions. This is out of scope for this PR, but if it's to happen it should occur before these are used in the many downstream repos under the org.

[seantronsen]

Is there a reason we are using the full ref associated with the tag and not just the tag itself? This repo doesn't appear to have a standard (some tags, some full refs).

Out of scope, but should we standardize later on? If so, I'll create a tracking issue.

[seantronsen]

Grammar mismatch. Var name is plural, doc comment is singular.

[seantronsen]

Ibid, see above grammar comment.

[seantronsen]

I do like this being an external script. We might want to refactor the other actions at some point to follow this design. Out of scope for now.

[seantronsen]

nitpick on code style: I'll defer to your judgement on this, but to me this part seems unnecessarily verbose since the script already requires the env vars utilized here. if the goal is to simply shorten the var names for future usage, we could just shorten the env vars and reference them directly?

As for checking + normalizing, we could use a loop func for this. Pasting an example below from one of my external projects:

function check-variable-assignments {

    if [ "${#}" -eq 0 ]; then
        echo "error: check-variable-assignments received zero arguments" >&2
        return 1
    fi

    local return_status=0
    while [ "${#}" -ne 0 ]; do
        local name="${1}"
        if [[ -v "${name}" ]]; then
            if [[ -n "${!name}" ]]; then
                echo "${name}=${!name}" >&2
            else
                echo "${name}: set but empty" >&2
                return_status=1
            fi
        else
            echo "${name}: required, but unset" >&2
            return_status=1
        fi
        shift
    done

    return "${return_status}"
}


# usage

check-variable-assignments \
    CERTIFICATE_AUTHORITY_URL \
    CERTIFICATE_AUTHORITY_PROVISIONER \
    FILEPATH_CERTIFICATE_AUTHORITY_CERT \
    FILEPATH_CERTIFICATE_AUTHORITY_PASSWD \
    SVC_DOMAIN \
    FILEPATH_CERT \
    FILEPATH_KEY \
    FILEPATH_COMBO \
    FILEPATH_COMBO_PFX \
    EXPECTED_UID \
    EXPECTED_GID \
    SVC_KEY_TYPE \
    SVC_KEY_CURVE || exit

Note

This is a little bit longer, but I'd argue:

1. it's more readable + maintainable in the long run
2. easy to reuse
3. it checks all var settings at the same time without erroring out until the end, meaning at runtime you'll discover all issues / typos simultaneously instead of one per execution.

[seantronsen]

For now, this is out of scope, but later on when we want to start supporting other distros, we might want to refactor this out to another github action.