feat: add RPM lockfile automation workflow

[polasudo]

Description

This PR adds automated RPM lockfile updates to the rhdh-operator repository, based on the automation already implemented in the main rhdh repository.
closes https://issues.redhat.com/browse/RHIDP-11434

Changes

Files Added:

• • Defines RPM packages required for the operator container
• • GitHub Action workflow for automated updates

Features:

• Weekly automated updates (every Monday at 3AM UTC)
• Trigger on package changes (when rpms.in.yaml or Dockerfiles change)
• Manual trigger via workflow_dispatch
• Auto-approval with lgtm and approved labels
• Branch-specific PRs for different release branches

Based on:

• PR #3342: Initial update-rpm-lockfile workflow
• PR #3427: Automated lgtm and build skip using rhdh-bot
• PR #3624: Enhanced RPM lockfile update to use unique branches

Requirements:

• secret needs to be configured in repository settings
• The workflow will create PRs automatically when RPM updates are available

Testing:

Test the workflow by triggering it manually via GitHub Actions UI.

[Zaperex]

@polasudo can you also add the initial rpms.lock.yaml in this PR?

[rm3l]

/review

[rhdh-qodo-merge]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🔒 Security concerns Supply chain: The workflow installs rpm-lockfile-prototype directly from https://github.com/konflux-ci/rpm-lockfile-prototype/archive/refs/heads/main.zip, which is a mutable reference and could be compromised or change unexpectedly. Pin to a specific release/tag/commit SHA (and ideally use a hash/attestation mechanism) to reduce supply-chain risk. Privileged token usage: The workflow uses secrets.RHDH_BOT_TOKEN to create PRs and then auto-applies lgtm/approved labels and posts /lgtm and /approved comments. Ensure the token scope is minimal and that repository governance expects automated approval signals, otherwise this can weaken review controls if the token is abused.

⚡ Recommended focus areas for review Supply Chain The workflow installs rpm-lockfile-prototype from a moving target (main.zip), which can lead to non-reproducible behavior and increases supply-chain risk. Consider pinning to a specific tag/commit SHA (or otherwise verifying integrity) so lockfile updates are deterministic and auditable. - name: Install rpm-lockfile-prototype run: | if [[ ! -x "${HOME}/.local/bin/rpm-lockfile-prototype" ]]; then echo "Installing rpm-lockfile-prototype ..." sudo apt-get update sudo apt-get install -y python3 python3-pip python3-dev build-essential sudo apt-get install -y podman skopeo rpm sudo apt-get install -y dnf python3-dnf mkdir -p "${HOME}/.local/bin/" python3 -m pip install --user https://github.com/konflux-ci/rpm-lockfile-prototype/archive/refs/heads/main.zip # Update PATH export PATH=${PATH%":${HOME}/.local/bin"}:${HOME}/.local/bin echo "${HOME}/.local/bin" >> $GITHUB_PATH Permissions The workflow writes to the repo and uses a powerful bot token to create/label/comment/approve PRs. Validate that permissions are least-privilege for the job and that RHDH_BOT_TOKEN is appropriately scoped (and preferably only used where required), since auto-labeling/commenting can bypass normal review intent if mis-scoped. permissions: contents: write env: DOCKERFILE_PATH: .rhdh/docker/Dockerfile jobs: update-lockfile: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # 4.3.0 with: fetch-depth: 0 - name: Check if hermetic Dockerfile exists run: | if [ ! -f "${{ env.DOCKERFILE_PATH }}" ]; then echo "Error: ${{ env.DOCKERFILE_PATH }} not found!" exit 1 fi - name: Configure Git run: | git config --global user.name "rhdh-bot" git config --global user.email "rhdh-bot@redhat.com" - name: Install rpm-lockfile-prototype run: | if [[ ! -x "${HOME}/.local/bin/rpm-lockfile-prototype" ]]; then echo "Installing rpm-lockfile-prototype ..." sudo apt-get update sudo apt-get install -y python3 python3-pip python3-dev build-essential sudo apt-get install -y podman skopeo rpm sudo apt-get install -y dnf python3-dnf mkdir -p "${HOME}/.local/bin/" python3 -m pip install --user https://github.com/konflux-ci/rpm-lockfile-prototype/archive/refs/heads/main.zip # Update PATH export PATH=${PATH%":${HOME}/.local/bin"}:${HOME}/.local/bin echo "${HOME}/.local/bin" >> $GITHUB_PATH else echo "rpm-lockfile-prototype already installed" fi - name: Run rpm-lockfile-prototype run: | echo "Running '${HOME}/.local/bin/rpm-lockfile-prototype -f ${{ env.DOCKERFILE_PATH }} rpms.in.yaml' in $(pwd)" ${HOME}/.local/bin/rpm-lockfile-prototype -f ${{ env.DOCKERFILE_PATH }} rpms.in.yaml - name: Check for lockfile changes id: check-lockfile-changes run: | if git diff --quiet rpms.lock.yaml; then echo "No changes to rpms.lock.yaml detected, skipping PR creation" echo "changes=false" >> $GITHUB_OUTPUT else echo "Changes detected in rpms.lock.yaml, creating PR" echo "changes=true" >> $GITHUB_OUTPUT fi - name: Determine target branch id: target-branch run: | TARGET_BRANCH="${{ github.ref_name }}" echo "name=${TARGET_BRANCH}" >> $GITHUB_OUTPUT echo "Target branch: ${TARGET_BRANCH}" - name: Create Pull Request id: create-pull-request if: steps.check-lockfile-changes.outputs.changes == 'true' uses: peter-evans/create-pull-request@271a8d0340265f705b14b6d32b9829c1cb33d45e # v7.0.8 with: token: ${{ secrets.RHDH_BOT_TOKEN }} commit-message: "chore: update rpms.lock.yaml [skip-build]" title: "chore: update RPM lockfile in branch (${{ steps.target-branch.outputs.name }}) [skip-build]" body: | ## Description This PR updates the `rpms.lock.yaml` file with the latest package versions based on current `rpms.in.yaml` configuration using `${{ env.DOCKERFILE_PATH }}` as the base container context This PR was automatically created by the [Update RPM Lockfile GitHub Action](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}). branch: chore/automated-update-rpm-lockfile/${{ steps.target-branch.outputs.name }} delete-branch: true draft: false sign-commits: true labels: | lgtm approved add-paths: | rpms.lock.yaml - name: Add /lgtm and /approved comment if: steps.check-lockfile-changes.outputs.changes == 'true' && steps.create-pull-request.outputs.pull-request-number != '' uses: actions/github-script@v7 with: github-token: ${{ secrets.RHDH_BOT_TOKEN }} script: | const body = "/lgtm\n/approved"; const prNumber = ${{ steps.create-pull-request.outputs.pull-request-number }}; github.rest.issues.createComment({ issue_number: parseInt(prNumber), owner: context.repo.owner, repo: context.repo.repo, body: body })

📄 References redhat-developer/rhdh-operator/config/profile/rhdh/plugin-deps/tekton.yaml [391-412] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-deps/tekton.yaml [117-151] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-deps/tekton.yaml [382-390] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-infra/pipeline.yaml [1-12] redhat-developer/rhdh-chart/charts/orchestrator-software-templates-infra/values.yaml [1-18] redhat-developer/rhdh-operator/config/manager/deployment.yaml [11-40] redhat-developer/rhdh-operator/dist/rhdh/install.yaml [2873-2910] redhat-developer/rhdh-operator/config/manager/deployment.yaml [41-49]

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rm3l]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rm3l

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [rm3l]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rm3l]

@polasudo Does this need to be cherrypicked to release-1.9?

[polasudo]

yes I believe so, since we might have another issue with operator being graded with C or lower

[rm3l]

yes I believe so, since we might have another issue with operator being graded with C or lower

/cherry-pick release-1.9

[openshift-cherrypick-robot]

@rm3l: new pull request created: #2156

Details

In response to this:

yes I believe so, since we might have another issue with operator being graded with C or lower

/cherry-pick release-1.9

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[polasudo]

/cherry-pick release-1.8

[polasudo]

/cherry-pick release-1.7

[openshift-cherrypick-robot]

@polasudo: only redhat-developer org members may request cherry picks. If you are already part of the org, make sure to change your membership to public. Otherwise you can still do the cherry-pick manually.

Details

In response to this:

/cherry-pick release-1.8

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-cherrypick-robot]

@polasudo: only redhat-developer org members may request cherry picks. If you are already part of the org, make sure to change your membership to public. Otherwise you can still do the cherry-pick manually.

Details

In response to this:

/cherry-pick release-1.7

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.