ci: auto-update bundle manifests on same-repo PRs by rm3l · Pull Request #3169 · redhat-developer/rhdh-operator

rm3l · 2026-07-09T10:51:09Z

Description

Update the PR bundle validation workflow to automatically regenerate and push bundle manifests when they are out of sync. For security, the auto-commit only runs on same-repo PRs (not forks), since fork PR events don't have access to repo secrets.

The auto-commit is best-effort. If the push fails, the workflow falls through to the existing error message guiding manual remediation.

Which issue(s) does this PR fix or relate to

—

This might be helpful for tagRelease PRs like #3164

PR acceptance criteria

Tests
Documentation

How to test changes / Special notes to the reviewer

Example same repo PR with auto-update: [TEST - DO NOT MERGE] ci: auto-update bundle manifests on same-repo PRs #3170
Example fork PR with auto-update skipped and failure: https://github.com/redhat-developer/rhdh-operator/actions/runs/29013366187/job/86102173883?pr=3169

Update the PR bundle validation workflow to automatically regenerate and push bundle manifests when they are out of sync, using the rhdh-bot identity so the push triggers CI. For security, the auto-commit only runs on same-repo PRs (not forks). It is best-effort — if the push fails, the workflow falls through to the existing error message guiding manual remediation. Assisted-by: Claude

Assisted-by: Claude

This reverts commit 7ac0c4d.

rhdh-qodo-merge · 2026-07-09T11:31:27Z

PR Summary by Qodo

ci: auto-update bundle manifests on same-repo PRs

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Regenerate bundle manifests during PR validation and detect meaningful diffs (ignoring createdAt).
• Auto-commit and push regenerated manifests for same-repo PRs using rhdh-bot credentials.
• Keep fork PRs secure by skipping auto-push and preserving the existing remediation failure
 message.

Diagram

graph TD
  B["Checkout PR branch"] --> C["Regenerate bundles"] --> D{"Out of sync?"}
  D -- "No" --> E(["Pass"])
  D -- "Yes" --> F{"Same-repo PR?"}
  F -- "Fork" --> I(["Fail w/ guidance"])
  F -- "Same repo" --> G["Auto-commit & push"] --> D

  subgraph Legend
    direction LR
    _act["Step"] ~~~ _dec{"Decision"} ~~~ _end(["Outcome"])
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Use pull_request_target to allow auto-push for forks

➕ Would allow auto-fixing manifests even for fork-based PRs
➕ Simplifies token/checkout branching logic
➖ Significant security risk: executes in base repo context with access to secrets
➖ Requires strict hardening (no untrusted code execution) and ongoing vigilance

2. Upload regenerated manifests as workflow artifact (no commit)

➕ Avoids any write permissions or secret usage for PR validation
➕ Still provides the exact fixed outputs for contributors to apply locally
➖ Does not keep the PR branch automatically up to date
➖ Adds manual steps for authors and may increase iteration time

3. Use a GitHub App with narrowly-scoped permissions for commits

➕ Better security posture than a broad PAT; auditable and revocable
➕ Can be configured with fine-grained repo/permission scopes
➖ More setup/ops overhead than using an existing bot token
➖ Still must avoid enabling writes for forks unless explicitly desired

Recommendation: The current approach is the best balance of developer experience and security: it auto-fixes same-repo PRs (where secrets/tokens are safe to use) while intentionally refusing to write on fork PRs. The best-effort push plus re-check preserves the existing failure guidance when automation can’t complete.

Files changed (1) +35 / -6

Other (1) +35 / -6

pr-bundle-diff-checks.yamlAuto-regenerate and (conditionally) auto-push bundle manifest fixes on PRs +35/-6

Auto-regenerate and (conditionally) auto-push bundle manifest fixes on PRs

• Adds contents:write permission and updates checkout to explicitly target the PR head repo/ref (supporting forks). Regenerates bundle manifests, detects meaningful diffs while ignoring createdAt churn, and conditionally commits/pushes fixes for same-repo PRs using the rhdh-bot token. If changes remain (or the PR is from a fork), the workflow fails with the existing remediation guidance.

.github/workflows/pr-bundle-diff-checks.yaml

rhdh-qodo-merge · 2026-07-09T11:37:39Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Context used

✅ Cross-repo context

Not relevant to this PR: redhat-developer/rhdh

Not relevant to this PR: redhat-developer/rhdh-plugins

1. Unvalidated RHDH_BOT_TOKEN/HEAD_REF ✓ Resolved 📘 Rule violation ☼ Reliability

Description

The workflow uses RHDH_BOT_TOKEN and HEAD_REF without validating they are set before embedding
them in the remote URL and refspec. If either is empty/unset, the step can behave unpredictably
(including failing with potentially confusing errors) rather than failing fast with a clear message.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R58-67]

+        env:
+          RHDH_BOT_TOKEN: ${{ secrets.RHDH_BOT_TOKEN }}
+          HEAD_REF: ${{ github.head_ref }}
+        run: |
+          git config user.name "rhdh-bot"
+          git config user.email "rhdh-bot@redhat.com"
+          git remote set-url origin "https://x-access-token:${RHDH_BOT_TOKEN}@github.com/${{ github.repository }}.git"
+          git add bundle/ config/ dist/
+          git commit -m "chore: regenerate bundle manifests"
+          if git push origin "HEAD:${HEAD_REF}"; then

Relevance

⭐⭐ Medium
No clear prior reviews enforcing ${VAR:?} env-var checks in workflows; team accepts some
shell/workflow hardening (PRs #1585,#751).
PR-#1585
PR-#751
PR-#2293

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 5 requires validating required environment variables. The updated workflow sets
RHDH_BOT_TOKEN/HEAD_REF and then uses them directly in git remote set-url and git push
without any ${VAR:?} / : "${VAR:?}" validation guard.

.github/workflows/pr-bundle-diff-checks.yaml[58-67]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `Auto-commit and push updated bundle manifests` step uses `RHDH_BOT_TOKEN` and `HEAD_REF` without required env var validation, violating the shell hardening requirement.

## Issue Context
These variables are consumed in the `git remote set-url` command and the `git push` refspec; missing values should fail fast with a clear error.

## Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[58-67]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Push failure false-green~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

The workflow commits regenerated manifests and allows git push to fail (`continue-on-error:
true`), but the subsequent “Fail if…” step only checks the local working tree. If the push fails
after a successful local commit, git diff becomes clean and the job exits 0 even though the PR
branch is still out of sync.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R54-72]

+      - name: Auto-commit and push updated bundle manifests
+        # Only attempt on same-repo PRs (not forks) for security; best-effort — failure falls through to the next step
+        if: steps.check.outputs.changed == 'true' && github.event.pull_request.head.repo.full_name == github.repository
+        continue-on-error: true
+        run: |
+          git config user.name "rhdh-bot"
+          git config user.email "rhdh-bot@redhat.com"
+          git add bundle/ config/ dist/
+          git commit -m "chore: regenerate bundle manifests"
+          git push
+
+      - name: Fail if bundle manifests are out of sync
+        if: steps.check.outputs.changed == 'true'
+        run: |
+          # Re-check in case the auto-commit step already pushed the fix
+          if git diff --quiet -I'^    createdAt: ' bundle config dist; then
+            echo "✅ Bundle manifests were auto-updated and pushed"
            exit 0
          fi

Relevance

⭐⭐ Medium
No direct precedent on push-failure handling; team sometimes tightens false-green CI logic (e.g., PR
#2828).
PR-#2828
PR-#1599

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The auto-commit step commits before pushing and ignores push failure; the later step’s git diff
check only reflects local repository state, so a failed push after a successful commit will still
look “clean” locally and incorrectly pass.

.github/workflows/pr-bundle-diff-checks.yaml[54-72]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow can report success even when the auto-push fails, because it commits locally and then later validates only via `git diff` (local state), not remote state.

### Issue Context
- `continue-on-error: true` makes push failures non-fatal.
- After a successful `git commit`, `git diff` becomes clean even if `git push` failed, causing the subsequent step to incorrectly `exit 0`.

### Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[54-72]

### Suggested fix approach
1. Give the auto-commit step an `id` (e.g., `autopush`) and write an output like `pushed=true/false`.
2. If `git push` fails, undo the local commit so the next step still sees a diff and fails (or explicitly fail based on `pushed=false`).
  - Example pattern inside the step:
    - run `git commit ...`
    - `if git push; then echo "pushed=true" >> $GITHUB_OUTPUT; else echo "pushed=false" >> $GITHUB_OUTPUT; git reset --hard HEAD~1; fi`
3. In the “Fail if…” step, only exit 0 when `steps.autopush.outputs.pushed == 'true'` (or otherwise keep failing when `changed=true`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~Reset hides changed files~~ ✓ Resolved 🐞 Bug ◔ Observability

Description

On git push failure, the workflow runs git reset --hard HEAD~1, which removes the regenerated
manifest changes from the working tree. The next step still runs git diff --name-only ... to list
changed files, but that list will be empty after the hard reset, making the failure output much less
actionable.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R67-68]

+            echo "pushed=false" >> "$GITHUB_OUTPUT"
+            git reset --hard HEAD~1

Relevance

⭐⭐⭐ High
Team accepted improving failure guidance/actionability in same workflow (PR #2293); likely accept
fix avoiding reset-hidden diffs.
PR-#2293
PR-#1599

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The autopush step hard-resets the repo after a push failure, and the later failure step computes the
changed-file list via git diff --name-only ...; after a hard reset, that diff will be empty even
though the earlier check reported changes.
.github/workflows/pr-bundle-diff-checks.yaml[54-69]
.github/workflows/pr-bundle-diff-checks.yaml[71-92]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
When `git push` fails, the workflow does `git reset --hard HEAD~1`, which discards the regenerated bundle changes. The following failure step prints `git diff --name-only ...` to show which files are out of sync, but after a hard reset the diff is empty.

### Issue Context
This only occurs on the best-effort auto-commit path when push fails, but that’s exactly when the workflow needs to provide the most actionable diagnostics.

### Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[64-69]

### Suggested fix
Replace the hard reset with a reset mode that preserves the working-tree changes for diagnostics, e.g.:
- `git reset --mixed HEAD~1` (or `--soft`), so the commit is removed but the regenerated files remain and `git diff --name-only ...` still reports the changed files.

(Alternative: capture `git diff --name-only ...` into an output variable before resetting, and print that in the fail step.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. ~~Bot token exposed to PR~~ ✓ Resolved 🐞 Bug ⛨ Security

Description

On same-repo PRs, actions/checkout uses secrets.RHDH_BOT_TOKEN, and by default persists it in
git credentials for the workspace; then make bundles build-installers runs PR-controlled code in
the same job. This enables PR code to read/exfiltrate the bot token from the checked-out repo’s git
config/credentials.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R23-30]

+      - name: Checkout PR branch
        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
        with:
+          repository: ${{ github.event.pull_request.head.repo.full_name }}
+          ref: ${{ github.head_ref }}
+          # Use rhdh-bot token for same-repo PRs (enables push); falls back to default for forks
+          token: ${{ secrets.RHDH_BOT_TOKEN || github.token }}
          fetch-depth: 0

Relevance

⭐⭐⭐ High
Team previously hardened workflows to avoid secrets exposure when running PR code (PRs #2293,
#1563).
PR-#2293
PR-#1563

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The checkout step configures a bot token for the repo, and the job later runs make from the PR
branch; with default checkout behavior, those credentials remain available in the workspace during
the build step.
.github/workflows/pr-bundle-diff-checks.yaml[23-30]
.github/workflows/pr-bundle-diff-checks.yaml[37-38]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow injects `RHDH_BOT_TOKEN` during checkout, and `actions/checkout` persists credentials by default; later steps execute PR-controlled code (`make ...`), which can access those persisted credentials.

### Issue Context
This primarily affects **same-repo PRs**, where `secrets.RHDH_BOT_TOKEN` is available and thus actually used.

### Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[23-30]
- .github/workflows/pr-bundle-diff-checks.yaml[37-38]
- .github/workflows/pr-bundle-diff-checks.yaml[54-63]

### Suggested fix approach
- Prefer using `github.token` for checkout and set `persist-credentials: false` to avoid leaving credentials in the repo for subsequent steps.
- Only inject `RHDH_BOT_TOKEN` in the auto-push step (scoped via `env:`) and set the remote URL just-in-time for the push, e.g.:
 - `git remote set-url origin https://x-access-token:${RHDH_BOT_TOKEN}@github.com/${{ github.repository }}.git`
 - `git push origin HEAD:${{ github.head_ref }}`
This limits exposure of the bot token to the smallest possible surface area.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Previous review results

Review updated until commit 2c4f22b

Results up to commit 1d7027e

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Push failure false-green~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

The workflow commits regenerated manifests and allows git push to fail (`continue-on-error:
true`), but the subsequent “Fail if…” step only checks the local working tree. If the push fails
after a successful local commit, git diff becomes clean and the job exits 0 even though the PR
branch is still out of sync.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R54-72]

+      - name: Auto-commit and push updated bundle manifests
+        # Only attempt on same-repo PRs (not forks) for security; best-effort — failure falls through to the next step
+        if: steps.check.outputs.changed == 'true' && github.event.pull_request.head.repo.full_name == github.repository
+        continue-on-error: true
+        run: |
+          git config user.name "rhdh-bot"
+          git config user.email "rhdh-bot@redhat.com"
+          git add bundle/ config/ dist/
+          git commit -m "chore: regenerate bundle manifests"
+          git push
+
+      - name: Fail if bundle manifests are out of sync
+        if: steps.check.outputs.changed == 'true'
+        run: |
+          # Re-check in case the auto-commit step already pushed the fix
+          if git diff --quiet -I'^    createdAt: ' bundle config dist; then
+            echo "✅ Bundle manifests were auto-updated and pushed"
            exit 0
          fi

Relevance

⭐⭐ Medium
No direct precedent on push-failure handling; team sometimes tightens false-green CI logic (e.g., PR
#2828).
PR-#2828
PR-#1599

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The auto-commit step commits before pushing and ignores push failure; the later step’s git diff
check only reflects local repository state, so a failed push after a successful commit will still
look “clean” locally and incorrectly pass.

.github/workflows/pr-bundle-diff-checks.yaml[54-72]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow can report success even when the auto-push fails, because it commits locally and then later validates only via `git diff` (local state), not remote state.

### Issue Context
- `continue-on-error: true` makes push failures non-fatal.
- After a successful `git commit`, `git diff` becomes clean even if `git push` failed, causing the subsequent step to incorrectly `exit 0`.

### Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[54-72]

### Suggested fix approach
1. Give the auto-commit step an `id` (e.g., `autopush`) and write an output like `pushed=true/false`.
2. If `git push` fails, undo the local commit so the next step still sees a diff and fails (or explicitly fail based on `pushed=false`).
  - Example pattern inside the step:
    - run `git commit ...`
    - `if git push; then echo "pushed=true" >> $GITHUB_OUTPUT; else echo "pushed=false" >> $GITHUB_OUTPUT; git reset --hard HEAD~1; fi`
3. In the “Fail if…” step, only exit 0 when `steps.autopush.outputs.pushed == 'true'` (or otherwise keep failing when `changed=true`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Bot token exposed to PR~~ ✓ Resolved 🐞 Bug ⛨ Security

Description

On same-repo PRs, actions/checkout uses secrets.RHDH_BOT_TOKEN, and by default persists it in
git credentials for the workspace; then make bundles build-installers runs PR-controlled code in
the same job. This enables PR code to read/exfiltrate the bot token from the checked-out repo’s git
config/credentials.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R23-30]

+      - name: Checkout PR branch
        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
        with:
+          repository: ${{ github.event.pull_request.head.repo.full_name }}
+          ref: ${{ github.head_ref }}
+          # Use rhdh-bot token for same-repo PRs (enables push); falls back to default for forks
+          token: ${{ secrets.RHDH_BOT_TOKEN || github.token }}
          fetch-depth: 0

Relevance

⭐⭐⭐ High
Team previously hardened workflows to avoid secrets exposure when running PR code (PRs #2293,
#1563).
PR-#2293
PR-#1563

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The checkout step configures a bot token for the repo, and the job later runs make from the PR
branch; with default checkout behavior, those credentials remain available in the workspace during
the build step.
.github/workflows/pr-bundle-diff-checks.yaml[23-30]
.github/workflows/pr-bundle-diff-checks.yaml[37-38]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow injects `RHDH_BOT_TOKEN` during checkout, and `actions/checkout` persists credentials by default; later steps execute PR-controlled code (`make ...`), which can access those persisted credentials.

### Issue Context
This primarily affects **same-repo PRs**, where `secrets.RHDH_BOT_TOKEN` is available and thus actually used.

### Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[23-30]
- .github/workflows/pr-bundle-diff-checks.yaml[37-38]
- .github/workflows/pr-bundle-diff-checks.yaml[54-63]

### Suggested fix approach
- Prefer using `github.token` for checkout and set `persist-credentials: false` to avoid leaving credentials in the repo for subsequent steps.
- Only inject `RHDH_BOT_TOKEN` in the auto-push step (scoped via `env:`) and set the remote URL just-in-time for the push, e.g.:
 - `git remote set-url origin https://x-access-token:${RHDH_BOT_TOKEN}@github.com/${{ github.repository }}.git`
 - `git push origin HEAD:${{ github.head_ref }}`
This limits exposure of the bot token to the smallest possible surface area.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 919999b

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Reset hides changed files~~ ✓ Resolved 🐞 Bug ◔ Observability

Description

On git push failure, the workflow runs git reset --hard HEAD~1, which removes the regenerated
manifest changes from the working tree. The next step still runs git diff --name-only ... to list
changed files, but that list will be empty after the hard reset, making the failure output much less
actionable.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R67-68]

+            echo "pushed=false" >> "$GITHUB_OUTPUT"
+            git reset --hard HEAD~1

Relevance

⭐⭐⭐ High
Team accepted improving failure guidance/actionability in same workflow (PR #2293); likely accept
fix avoiding reset-hidden diffs.
PR-#2293
PR-#1599

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The autopush step hard-resets the repo after a push failure, and the later failure step computes the
changed-file list via git diff --name-only ...; after a hard reset, that diff will be empty even
though the earlier check reported changes.
.github/workflows/pr-bundle-diff-checks.yaml[54-69]
.github/workflows/pr-bundle-diff-checks.yaml[71-92]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
When `git push` fails, the workflow does `git reset --hard HEAD~1`, which discards the regenerated bundle changes. The following failure step prints `git diff --name-only ...` to show which files are out of sync, but after a hard reset the diff is empty.

### Issue Context
This only occurs on the best-effort auto-commit path when push fails, but that’s exactly when the workflow needs to provide the most actionable diagnostics.

### Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[64-69]

### Suggested fix
Replace the hard reset with a reset mode that preserves the working-tree changes for diagnostics, e.g.:
- `git reset --mixed HEAD~1` (or `--soft`), so the commit is removed but the regenerated files remain and `git diff --name-only ...` still reports the changed files.

(Alternative: capture `git diff --name-only ...` into an output variable before resetting, and print that in the fail step.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit cb1d96c

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Unvalidated RHDH_BOT_TOKEN/HEAD_REF ✓ Resolved 📘 Rule violation ☼ Reliability

Description

The workflow uses RHDH_BOT_TOKEN and HEAD_REF without validating they are set before embedding
them in the remote URL and refspec. If either is empty/unset, the step can behave unpredictably
(including failing with potentially confusing errors) rather than failing fast with a clear message.

Code

.github/workflows/pr-bundle-diff-checks.yaml[R58-67]

+        env:
+          RHDH_BOT_TOKEN: ${{ secrets.RHDH_BOT_TOKEN }}
+          HEAD_REF: ${{ github.head_ref }}
+        run: |
+          git config user.name "rhdh-bot"
+          git config user.email "rhdh-bot@redhat.com"
+          git remote set-url origin "https://x-access-token:${RHDH_BOT_TOKEN}@github.com/${{ github.repository }}.git"
+          git add bundle/ config/ dist/
+          git commit -m "chore: regenerate bundle manifests"
+          if git push origin "HEAD:${HEAD_REF}"; then

Relevance

⭐⭐ Medium
No clear prior reviews enforcing ${VAR:?} env-var checks in workflows; team accepts some
shell/workflow hardening (PRs #1585,#751).
PR-#1585
PR-#751
PR-#2293

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 5 requires validating required environment variables. The updated workflow sets
RHDH_BOT_TOKEN/HEAD_REF and then uses them directly in git remote set-url and git push
without any ${VAR:?} / : "${VAR:?}" validation guard.

.github/workflows/pr-bundle-diff-checks.yaml[58-67]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `Auto-commit and push updated bundle manifests` step uses `RHDH_BOT_TOKEN` and `HEAD_REF` without required env var validation, violating the shell hardening requirement.

## Issue Context
These variables are consumed in the `git remote set-url` command and the `git push` refspec; missing values should fail fast with a clear error.

## Fix Focus Areas
- .github/workflows/pr-bundle-diff-checks.yaml[58-67]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

…le-manifests-on-pr

If git push fails, the local commit leaves the working tree clean, causing the subsequent validation step to incorrectly report success. Reset the commit on push failure so the diff stays dirty, and gate the success path on the pushed output instead of re-checking git diff. Assisted-by: Claude

rm3l · 2026-07-17T09:16:00Z

/agentic_review

Avoid persisting the bot token during checkout where PR-controlled code (make bundles) could access it. Instead, use persist-credentials: false and inject the token only in the push step via a scoped env var and just-in-time git remote set-url. Assisted-by: Claude

rhdh-qodo-merge · 2026-07-17T09:20:05Z

Code review by qodo was updated up to the latest commit 919999b

git reset --hard discards the regenerated files, leaving git diff empty in the failure step. Use --mixed instead so the commit is undone but the changed files remain in the working tree for diagnostic output. Assisted-by: Claude

Assigning github.head_ref to an environment variable avoids injecting user-controlled data directly into the run block. Assisted-by: Claude

…le-manifests-on-pr

rm3l · 2026-07-17T09:25:16Z

/agentic_review

rhdh-qodo-merge · 2026-07-17T09:37:10Z

Code review by qodo was updated up to the latest commit cb1d96c

Exit early with a warning if RHDH_BOT_TOKEN or HEAD_REF is missing. The autopush output remains unset, so the subsequent step still correctly fails the workflow and reports the outdated bundle manifests. Assisted-by: Claude

rm3l · 2026-07-17T09:40:55Z

/agentic_review

sonarqubecloud · 2026-07-17T09:41:04Z

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

rhdh-qodo-merge · 2026-07-17T09:49:17Z

Code review by qodo was updated up to the latest commit 2c4f22b

openshift-ci Bot added the do-not-merge/work-in-progress label Jul 9, 2026

rm3l added 2 commits July 9, 2026 12:56

fix: specify repository in checkout for fork PR branches

639ad61

Assisted-by: Claude

test: bump VERSION to trigger outdated bundle (will revert)

7ac0c4d

rm3l mentioned this pull request Jul 9, 2026

[TEST - DO NOT MERGE] ci: auto-update bundle manifests on same-repo PRs #3170

Closed

Revert "test: bump VERSION to trigger outdated bundle (will revert)"

1d7027e

This reverts commit 7ac0c4d.

rm3l marked this pull request as ready for review July 9, 2026 11:30

rm3l requested a review from a team as a code owner July 9, 2026 11:30

openshift-ci Bot removed the do-not-merge/work-in-progress label Jul 9, 2026

openshift-ci Bot requested review from Fortune-Ndlovu and gazarenkov July 9, 2026 11:30

rhdh-qodo-merge Bot reviewed Jul 9, 2026

View reviewed changes

Comment thread .github/workflows/pr-bundle-diff-checks.yaml Outdated

rhdh-qodo-merge Bot added enhancement New feature or request Tests labels Jul 9, 2026

rm3l added 2 commits July 17, 2026 11:13

Merge remote-tracking branch 'upstream/main' into ci/auto-update-bund…

bc48097

…le-manifests-on-pr

github-advanced-security AI found potential problems Jul 17, 2026

View reviewed changes

Comment thread .github/workflows/pr-bundle-diff-checks.yaml Fixed

rm3l added 3 commits July 17, 2026 11:21

fix: pass github.head_ref via env var to prevent script injection

ca7a4aa

Assigning github.head_ref to an environment variable avoids injecting user-controlled data directly into the run block. Assisted-by: Claude

Merge remote-tracking branch 'upstream/main' into ci/auto-update-bund…

cb1d96c

…le-manifests-on-pr

rhdh-qodo-merge Bot reviewed Jul 17, 2026

View reviewed changes

Comment thread .github/workflows/pr-bundle-diff-checks.yaml

fix: skip auto-push when required env vars are not set

2c4f22b

Exit early with a warning if RHDH_BOT_TOKEN or HEAD_REF is missing. The autopush output remains unset, so the subsequent step still correctly fails the workflow and reports the outdated bundle manifests. Assisted-by: Claude

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

ci: auto-update bundle manifests on same-repo PRs#3169

ci: auto-update bundle manifests on same-repo PRs#3169
rm3l wants to merge 11 commits into
redhat-developer:mainfrom
rm3l:ci/auto-update-bundle-manifests-on-pr

rm3l commented Jul 9, 2026 •

edited

Loading

Uh oh!

rhdh-qodo-merge Bot commented Jul 9, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jul 9, 2026 •

edited

Loading

Uh oh!

Uh oh!

rm3l commented Jul 17, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jul 17, 2026

Uh oh!

Uh oh!

rm3l commented Jul 17, 2026

Uh oh!

Uh oh!

rhdh-qodo-merge Bot commented Jul 17, 2026

Uh oh!

rm3l commented Jul 17, 2026

Uh oh!

sonarqubecloud Bot commented Jul 17, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

rm3l commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Which issue(s) does this PR fix or relate to

PR acceptance criteria

How to test changes / Special notes to the reviewer

Uh oh!

rhdh-qodo-merge Bot commented Jul 9, 2026

PR Summary by Qodo

Uh oh!

rhdh-qodo-merge Bot commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

Uh oh!

rm3l commented Jul 17, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jul 17, 2026

Uh oh!

Uh oh!

rm3l commented Jul 17, 2026

Uh oh!

Uh oh!

rhdh-qodo-merge Bot commented Jul 17, 2026

Uh oh!

rm3l commented Jul 17, 2026

Uh oh!

sonarqubecloud Bot commented Jul 17, 2026

Quality Gate passed

Uh oh!

rhdh-qodo-merge Bot commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rm3l commented Jul 9, 2026 •

edited

Loading

rhdh-qodo-merge Bot commented Jul 9, 2026 •

edited

Loading