feat: create separate PRs per branch for downstream repos in cve.fix#101
Open
vmrh21 wants to merge 4 commits intoambient-code:mainfrom
Open
feat: create separate PRs per branch for downstream repos in cve.fix#101vmrh21 wants to merge 4 commits intoambient-code:mainfrom
vmrh21 wants to merge 4 commits intoambient-code:mainfrom
Conversation
- upstream/midstream: PR against default_branch only (main) - downstream: separate PR for default_branch + each active_release_branch Each branch is independently fixed and gets its own PR — never combined. Fix branch naming includes the target branch for clarity, e.g.: fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1 No mapping file changes needed — logic derived from existing repo_type, default_branch, and active_release_branches fields. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
WalkthroughCVE workflow docs updated: cve.fix now determines target branches from Changes
Sequence Diagram(s)sequenceDiagram
participant WF as Workflow
participant GH as GitHub API (gh)
participant Git as Local Git
participant Remote as Remote Repo (origin)
participant Fork as Fork Repo
participant Jira as Jira API
WF->>GH: authenticate using Classic PAT (`gh auth login`)
WF->>Git: git clone --depth=1 /tmp/<org>/<name>
WF->>GH: check push permission via `gh api` (can_push?)
alt has write access
WF->>Git: for each TARGET_BRANCH: git checkout & git pull
WF->>Git: apply fixes, commit, create branch
Git->>Remote: git push branch
WF->>GH: create PR to origin
else no write access
WF->>Fork: push branch to fork
WF->>GH: create PR from fork -> origin
end
WF->>Jira: if CVE not found → add VEX justification (auto or human-review artifact)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 163-172: Update the fenced code blocks in
workflows/cve-fixer/.claude/commands/cve.fix.md to satisfy MD031/MD040 by adding
explicit language identifiers (e.g., ```text for the plain table and ```bash for
the shell block) and ensuring there is a blank line before and after each fenced
block; locate the blocks using the existing fence markers (``` and ```bash) and
the shown content ("upstream llm-d/..." table and the "# Clone once:" shell
example) and insert the missing blank lines and the language tag on the opening
fence for each block.
- Around line 174-179: The branch naming guidance is inconsistent: the
multi-branch example uses a target-branch token (e.g.,
fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1) but the canonical rule later
omits it (fix/cve-...-<package>-attempt-1), risking collisions across base
branches; update the canonical naming rule to include a target-branch
placeholder (e.g., <target-branch> or the actual base branch name) and make both
the example and the canonical pattern consistent so every fix branch (symbols:
fix/cve-YYYY-XXXXX-<package>-<target-branch>-attempt-N) uniquely identifies the
base branch and prevents reuse/overwrite when repeating steps 4–11 for each
branch.
- Around line 183-191: The current flow that "Clone the repo once" then loops
over TARGET_BRANCHES (steps 5–11) can leak state between branch iterations;
update the procedure so each target branch runs in an isolated workspace: for
each branch in TARGET_BRANCHES either (a) create a fresh clone (git clone into a
new REPO_DIR per branch) or (b) perform a strict reset (git fetch --all; git
checkout <branch>; git reset --hard origin/<branch>; git clean -fdx) before
applying fixes, and ensure git credentials configuration (gh auth setup-git /
credential.helper / SSH fallback) is applied for each cloned workspace so
pushes/PRs cannot be affected by artifacts, uncommitted changes, or lockfile
drift from previous iterations.
- Around line 155-159: The TARGET_BRANCHES array construction can include
duplicates if ACTIVE_RELEASE_BRANCHES contains DEFAULT_BRANCH; change the logic
that sets TARGET_BRANCHES (the branch assembly around TARGET_BRANCHES,
DEFAULT_BRANCH and ACTIVE_RELEASE_BRANCHES) to deduplicate entries before use —
for example, build TARGET_BRANCHES by iterating DEFAULT_BRANCH and each element
of ACTIVE_RELEASE_BRANCHES and only appending branches not already present (or
use a temporary associative set) so TARGET_BRANCHES contains unique branch names
and avoids duplicate PR attempts.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: dcde3137-0bcb-4cf1-9ef6-55b5f3a67393
📒 Files selected for processing (1)
workflows/cve-fixer/.claude/commands/cve.fix.md
Comment on lines
+155
to
+159
| if [ "$REPO_TYPE" = "downstream" ]; then | ||
| TARGET_BRANCHES=("$DEFAULT_BRANCH" "${ACTIVE_RELEASE_BRANCHES[@]}") | ||
| else | ||
| TARGET_BRANCHES=("$DEFAULT_BRANCH") | ||
| fi |
There was a problem hiding this comment.
TARGET_BRANCHES needs deduplication to avoid duplicate PR attempts.
If ACTIVE_RELEASE_BRANCHES contains DEFAULT_BRANCH, this creates duplicate targets and can trigger redundant PR creation/push conflicts.
Suggested doc fix
- if [ "$REPO_TYPE" = "downstream" ]; then
- TARGET_BRANCHES=("$DEFAULT_BRANCH" "${ACTIVE_RELEASE_BRANCHES[@]}")
- else
- TARGET_BRANCHES=("$DEFAULT_BRANCH")
- fi
+ if [ "$REPO_TYPE" = "downstream" ]; then
+ TARGET_BRANCHES=("$DEFAULT_BRANCH" "${ACTIVE_RELEASE_BRANCHES[@]}")
+ else
+ TARGET_BRANCHES=("$DEFAULT_BRANCH")
+ fi
+
+ # Deduplicate while preserving order
+ UNIQUE_TARGET_BRANCHES=()
+ for b in "${TARGET_BRANCHES[@]}"; do
+ [[ -z "$b" ]] && continue
+ [[ " ${UNIQUE_TARGET_BRANCHES[*]} " == *" $b "* ]] || UNIQUE_TARGET_BRANCHES+=("$b")
+ done
+ TARGET_BRANCHES=("${UNIQUE_TARGET_BRANCHES[@]}")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if [ "$REPO_TYPE" = "downstream" ]; then | |
| TARGET_BRANCHES=("$DEFAULT_BRANCH" "${ACTIVE_RELEASE_BRANCHES[@]}") | |
| else | |
| TARGET_BRANCHES=("$DEFAULT_BRANCH") | |
| fi | |
| if [ "$REPO_TYPE" = "downstream" ]; then | |
| TARGET_BRANCHES=("$DEFAULT_BRANCH" "${ACTIVE_RELEASE_BRANCHES[@]}") | |
| else | |
| TARGET_BRANCHES=("$DEFAULT_BRANCH") | |
| fi | |
| # Deduplicate while preserving order | |
| UNIQUE_TARGET_BRANCHES=() | |
| for b in "${TARGET_BRANCHES[@]}"; do | |
| [[ -z "$b" ]] && continue | |
| [[ " ${UNIQUE_TARGET_BRANCHES[*]} " == *" $b "* ]] || UNIQUE_TARGET_BRANCHES+=("$b") | |
| done | |
| TARGET_BRANCHES=("${UNIQUE_TARGET_BRANCHES[@]}") |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 155 - 159, The
TARGET_BRANCHES array construction can include duplicates if
ACTIVE_RELEASE_BRANCHES contains DEFAULT_BRANCH; change the logic that sets
TARGET_BRANCHES (the branch assembly around TARGET_BRANCHES, DEFAULT_BRANCH and
ACTIVE_RELEASE_BRANCHES) to deduplicate entries before use — for example, build
TARGET_BRANCHES by iterating DEFAULT_BRANCH and each element of
ACTIVE_RELEASE_BRANCHES and only appending branches not already present (or use
a temporary associative set) so TARGET_BRANCHES contains unique branch names and
avoids duplicate PR attempts.
Comment on lines
+174
to
179
| **Multi-repo + multi-branch strategy**: | ||
| - Fix upstream repos first, then midstream, then downstream | ||
| - For downstream: Steps 4 through 11 repeat for EACH branch independently | ||
| - Each branch produces its own PR with its own fix branch (e.g., `fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1`) | ||
| - Never combine fixes for multiple branches into a single PR | ||
|
|
There was a problem hiding this comment.
Branch naming rule is still inconsistent and can collide across target branches.
This section says branch names include the target branch, but the canonical naming rule later still omits it (fix/cve-...-<package>-attempt-1). That can overwrite/reuse the same fix branch name for multiple base branches.
Suggested doc fix
- - Use consistent naming: `fix/cve-YYYY-XXXXX-<package-name>-attempt-1`
+ - Use consistent naming: `fix/cve-YYYY-XXXXX-<package-name>-<target-branch>-attempt-1`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 174 - 179, The
branch naming guidance is inconsistent: the multi-branch example uses a
target-branch token (e.g., fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1) but
the canonical rule later omits it (fix/cve-...-<package>-attempt-1), risking
collisions across base branches; update the canonical naming rule to include a
target-branch placeholder (e.g., <target-branch> or the actual base branch name)
and make both the example and the canonical pattern consistent so every fix
branch (symbols: fix/cve-YYYY-XXXXX-<package>-<target-branch>-attempt-N)
uniquely identifies the base branch and prevents reuse/overwrite when repeating
steps 4–11 for each branch.
Ambient sessions inject secrets differently — JIRA_API_TOKEN and JIRA_EMAIL may be available to API calls even when not visible to bash [ -z "$VAR" ] checks, causing false "missing credentials" errors. Replace the upfront env var check with a lightweight GET /myself test call: proceed on 200, only complain on 401/403. Never hard-stop just because the shell check returns empty. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.find.md`:
- Around line 83-87: Insert a single blank line before the fenced code block in
the "a. Set up variables (AUTH already set from Step 2):" list item so the
markdown has a blank line immediately before the ```bash fence (fixing MD031).
Locate the fenced block in workflows/cve-fixer/.claude/commands/cve.find.md
under the "COMPONENT_NAME" setup section and add the blank line above the
```bash line to make the block compliant.
- Around line 69-75: The fenced code block starting with "```bash" containing
the export lines currently lacks surrounding blank lines (MD031); add one blank
line immediately before the opening "```bash" and one blank line immediately
after the closing "```" so the code block is separated from the surrounding list
text (update the block in workflows/cve-fixer/.claude/commands/cve.find.md where
the export JIRA_API_TOKEN/JIRA_EMAIL lines appear).
- Around line 58-79: The curl healthcheck using JIRA_BASE_URL and TEST_RESPONSE
should not treat HTTP 403 as "insufficient permissions" because
/rest/api/3/myself returns 401 for both auth failures and permission issues;
update the logic that branches on TEST_RESPONSE to consolidate 401 handling (log
both missing/invalid creds and insufficient permissions together and instruct
the user to check API token/email and permissions) and remove or disable the
separate 403 branch, or alternatively replace the endpoint with a
permissions-specific endpoint if you really need to distinguish 403; keep the
existing note about not pre-checking env vars (do not add a [ -z
"$JIRA_API_TOKEN" ] check).
- Around line 58-77: The documentation says to "retry once" on network/timeout
but the TEST_RESPONSE curl call lacks retry options; update the curl invocation
that sets TEST_RESPONSE (the command using JIRA_BASE_URL and AUTH) to perform a
single retry on transient failures by adding curl retry flags (e.g., --retry 1
plus an appropriate --retry-delay and --retry-connrefused) while preserving
existing timeouts (--connect-timeout, --max-time) and the exit-code capture (-s
-o /dev/null -w "%{http_code}"); ensure the adjusted curl still returns an HTTP
status code into TEST_RESPONSE so the subsequent HTTP 200/401/403/Other handling
continues to work.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2f7d15b0-6ed9-419e-b03a-15674de9f5c6
📒 Files selected for processing (1)
workflows/cve-fixer/.claude/commands/cve.find.md
Comment on lines
+58
to
+79
| ```bash | ||
| JIRA_BASE_URL="https://redhat.atlassian.net" | ||
| AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64) | ||
| TEST_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X GET \ | ||
| --connect-timeout 10 --max-time 15 \ | ||
| -H "Authorization: Basic ${AUTH}" \ | ||
| -H "Content-Type: application/json" \ | ||
| "${JIRA_BASE_URL}/rest/api/3/myself") | ||
| ``` | ||
|
|
||
| - **HTTP 200** → credentials valid, proceed | ||
| - **HTTP 401** → credentials missing or invalid. Only now inform the user: | ||
| - Check if `JIRA_API_TOKEN` and `JIRA_EMAIL` are configured as Ambient session secrets | ||
| - If not, generate a token at https://id.atlassian.com/manage-profile/security/api-tokens and export: | ||
| ```bash | ||
| export JIRA_API_TOKEN="your-token-here" | ||
| export JIRA_EMAIL="your-email@redhat.com" | ||
| ``` | ||
| - **HTTP 403** → token valid but insufficient permissions — inform user | ||
| - **Other / timeout** → network issue — inform user and retry once | ||
|
|
||
| **Do NOT pre-check env vars with `[ -z "$JIRA_API_TOKEN" ]` and stop.** The variables may be available to the API call even if not visible to the shell check (e.g. Ambient secrets injection). |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the recommended Jira REST API v3 endpoint for testing authentication credentials, and what HTTP status codes does it return for valid credentials, invalid credentials, and insufficient permissions?
💡 Result:
The recommended Jira REST API v3 endpoint for testing authentication credentials is GET /rest/api/3/myself. This endpoint returns details for the current authenticated user and requires only "Permission to access Jira". HTTP status codes: - Valid credentials: 200 OK - Invalid credentials: 401 Unauthorized - Insufficient permissions: This endpoint has minimal permissions required (access Jira), so insufficient permissions would also return 401 Unauthorized if the user lacks basic access. Alternative endpoint for permission checks: GET /rest/api/3/mypermissions, which returns the user's permissions and can be used to verify more granular access. It returns 200 OK for valid authenticated users. Note: There is no dedicated "health check" or ping endpoint solely for auth testing in official docs; /myself is commonly used as it confirms successful authentication and basic access.
Citations:
- 1: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-myself/
- 2: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-myself
- 3: https://community.atlassian.com/forums/Jira-questions/What-Permissions-or-Setup-Are-Needed-for-a-Managed-User-to-Use/qaq-p/3118599
- 4: https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/
- 5: https://jira-api.apidog.io/api-3933549
- 6: https://developer.atlassian.com/server/jira-servicedesk/rest/v1103/api-group-mypermissions/
Reconsider the HTTP 403 status code—/rest/api/3/myself returns 401 for all authentication failures.
The endpoint is correct for credentials validation. However, the /rest/api/3/myself endpoint returns HTTP 401 for both missing/invalid credentials and insufficient permissions. The current code handles HTTP 403 as a separate "insufficient permissions" case, but this endpoint does not return 403 per official Jira REST API v3 documentation.
Consolidate error handling to treat 401 responses uniformly, or verify that a different endpoint is intended for the 403 case.
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 72-72: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 75-75: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.find.md` around lines 58 - 79, The
curl healthcheck using JIRA_BASE_URL and TEST_RESPONSE should not treat HTTP 403
as "insufficient permissions" because /rest/api/3/myself returns 401 for both
auth failures and permission issues; update the logic that branches on
TEST_RESPONSE to consolidate 401 handling (log both missing/invalid creds and
insufficient permissions together and instruct the user to check API token/email
and permissions) and remove or disable the separate 403 branch, or alternatively
replace the endpoint with a permissions-specific endpoint if you really need to
distinguish 403; keep the existing note about not pre-checking env vars (do not
add a [ -z "$JIRA_API_TOKEN" ] check).
Comment on lines
+58
to
+77
| ```bash | ||
| JIRA_BASE_URL="https://redhat.atlassian.net" | ||
| AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64) | ||
| TEST_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X GET \ | ||
| --connect-timeout 10 --max-time 15 \ | ||
| -H "Authorization: Basic ${AUTH}" \ | ||
| -H "Content-Type: application/json" \ | ||
| "${JIRA_BASE_URL}/rest/api/3/myself") | ||
| ``` | ||
|
|
||
| - **HTTP 200** → credentials valid, proceed | ||
| - **HTTP 401** → credentials missing or invalid. Only now inform the user: | ||
| - Check if `JIRA_API_TOKEN` and `JIRA_EMAIL` are configured as Ambient session secrets | ||
| - If not, generate a token at https://id.atlassian.com/manage-profile/security/api-tokens and export: | ||
| ```bash | ||
| export JIRA_API_TOKEN="your-token-here" | ||
| export JIRA_EMAIL="your-email@redhat.com" | ||
| ``` | ||
| - **HTTP 403** → token valid but insufficient permissions — inform user | ||
| - **Other / timeout** → network issue — inform user and retry once |
There was a problem hiding this comment.
Implement retry logic for timeout handling.
Line 77 documents that timeout/network errors should "retry once," but the test API call in lines 58-66 lacks retry flags. This creates a documentation-implementation gap.
🔄 Proposed fix to add retry logic
TEST_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X GET \
--connect-timeout 10 --max-time 15 \
+ --retry 1 \
+ --retry-delay 2 \
+ --retry-connrefused \
-H "Authorization: Basic ${AUTH}" \
-H "Content-Type: application/json" \
"${JIRA_BASE_URL}/rest/api/3/myself")🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 72-72: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 75-75: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.find.md` around lines 58 - 77, The
documentation says to "retry once" on network/timeout but the TEST_RESPONSE curl
call lacks retry options; update the curl invocation that sets TEST_RESPONSE
(the command using JIRA_BASE_URL and AUTH) to perform a single retry on
transient failures by adding curl retry flags (e.g., --retry 1 plus an
appropriate --retry-delay and --retry-connrefused) while preserving existing
timeouts (--connect-timeout, --max-time) and the exit-code capture (-s -o
/dev/null -w "%{http_code}"); ensure the adjusted curl still returns an HTTP
status code into TEST_RESPONSE so the subsequent HTTP 200/401/403/Other handling
continues to work.
Comment on lines
+69
to
+75
| - **HTTP 401** → credentials missing or invalid. Only now inform the user: | ||
| - Check if `JIRA_API_TOKEN` and `JIRA_EMAIL` are configured as Ambient session secrets | ||
| - If not, generate a token at https://id.atlassian.com/manage-profile/security/api-tokens and export: | ||
| ```bash | ||
| export JIRA_API_TOKEN="your-token-here" | ||
| export JIRA_EMAIL="your-email@redhat.com" | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add blank lines around fenced code blocks for markdown compliance.
Markdownlint reports missing blank lines around the code block per MD031. Add a blank line before line 72 and after line 75 to improve formatting consistency.
📝 Proposed formatting fix
- **HTTP 401** → credentials missing or invalid. Only now inform the user:
- Check if `JIRA_API_TOKEN` and `JIRA_EMAIL` are configured as Ambient session secrets
- If not, generate a token at https://id.atlassian.com/manage-profile/security/api-tokens and export:
+
```bash
export JIRA_API_TOKEN="your-token-here"
export JIRA_EMAIL="your-email@redhat.com"
```
+
- **HTTP 403** → token valid but insufficient permissions — inform user🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 72-72: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 75-75: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.find.md` around lines 69 - 75, The
fenced code block starting with "```bash" containing the export lines currently
lacks surrounding blank lines (MD031); add one blank line immediately before the
opening "```bash" and one blank line immediately after the closing "```" so the
code block is separated from the surrounding list text (update the block in
workflows/cve-fixer/.claude/commands/cve.find.md where the export
JIRA_API_TOKEN/JIRA_EMAIL lines appear).
Comment on lines
+83
to
+87
| a. Set up variables (AUTH already set from Step 2): | ||
| ```bash | ||
| COMPONENT_NAME="[from step 1]" | ||
| JIRA_BASE_URL="https://redhat.atlassian.net" | ||
| JIRA_EMAIL="${JIRA_EMAIL}" | ||
| JIRA_API_TOKEN="${JIRA_API_TOKEN}" | ||
| # Jira Cloud uses Basic Auth: base64(email:api-token) | ||
| AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64) | ||
| # AUTH already constructed in Step 2 — reuse it |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add blank line before fenced code block for markdown compliance.
Markdownlint reports a missing blank line before the code block at line 84 per MD031.
📝 Proposed formatting fix
3. **Query Jira for CVE Issues**
a. Set up variables (AUTH already set from Step 2):
+
```bash
COMPONENT_NAME="[from step 1]"
JIRA_BASE_URL="https://redhat.atlassian.net"🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 84-84: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.find.md` around lines 83 - 87,
Insert a single blank line before the fenced code block in the "a. Set up
variables (AUTH already set from Step 2):" list item so the markdown has a blank
line immediately before the ```bash fence (fixing MD031). Locate the fenced
block in workflows/cve-fixer/.claude/commands/cve.find.md under the
"COMPONENT_NAME" setup section and add the blank line above the ```bash line to
make the block compliant.
…access repos - Recommend Classic PAT with repo scope over fine-grained PAT or Ambient Code GitHub App (neither works reliably for cross-org repos like llm-d/*, eval-hub/*, trustyai-explainability/*) - Add write access check: use gh api repos/X --jq '.permissions.push' before attempting to push - Add fork fallback: if no write access, create fork, push fix branch to fork, and open PR targeting the original repo with head: user:branch This handles all upstream external org repos automatically Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
♻️ Duplicate comments (4)
workflows/cve-fixer/.claude/commands/cve.fix.md (4)
153-160:⚠️ Potential issue | 🟠 MajorDeduplicate
TARGET_BRANCHESbefore processing to prevent duplicate PR attempts.If
ACTIVE_RELEASE_BRANCHEScontainsDEFAULT_BRANCH, this list can duplicate targets and cause redundant PR/push attempts.Suggested doc fix
if [ "$REPO_TYPE" = "downstream" ]; then TARGET_BRANCHES=("$DEFAULT_BRANCH" "${ACTIVE_RELEASE_BRANCHES[@]}") else TARGET_BRANCHES=("$DEFAULT_BRANCH") fi + +# Deduplicate while preserving order +UNIQUE_TARGET_BRANCHES=() +for b in "${TARGET_BRANCHES[@]}"; do + [ -z "$b" ] && continue + [[ " ${UNIQUE_TARGET_BRANCHES[*]} " == *" $b "* ]] || UNIQUE_TARGET_BRANCHES+=("$b") +done +TARGET_BRANCHES=("${UNIQUE_TARGET_BRANCHES[@]}")🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 153 - 160, The TARGET_BRANCHES assignment can produce duplicates when ACTIVE_RELEASE_BRANCHES includes DEFAULT_BRANCH; update the logic that builds TARGET_BRANCHES (the block using REPO_TYPE, DEFAULT_BRANCH and ACTIVE_RELEASE_BRANCHES) to deduplicate entries before further processing — for example, after composing TARGET_BRANCHES, iterate and rebuild a new array using a seen set (declare -A seen) to skip already-added branch names so each branch appears only once; ensure downstream consumers of TARGET_BRANCHES use the deduplicated array.
162-173:⚠️ Potential issue | 🟡 MinorFix fenced code block formatting for markdownlint compliance (MD031/MD040).
This fence is missing a language identifier and blank-line framing.
Suggested doc fix
- ``` + + ```text upstream llm-d/llm-d-inference-scheduler → PR against: main midstream opendatahub-io/llm-d-inference-scheduler → PR against: main downstream red-hat-data-services/llm-d-inference-scheduler → PRs against: - main - rhoai-3.3 - rhoai-3.4 - rhoai-3.4-ea.1 - rhoai-3.4-ea.2 ``` +🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 162 - 173, The fenced code block for the "llm-d inference-scheduler" example is missing a language identifier and blank-line framing; update the markdown by adding a blank line before and after the triple-backtick fence and include a language token (e.g., "text") after the opening ``` so the block around the "upstream llm-d/llm-d-inference-scheduler ..." example is fenced as ```text ... ``` to satisfy MD031/MD040.
206-207:⚠️ Potential issue | 🟠 MajorSingle-clone branch loop still contradicts per-target isolated execution.
Current guidance still uses one clone + checkout loop, which risks state leakage across target branches and conflicts with the PR objective of independent clone→fix→test→PR per branch.
Suggested doc fix
-REPO_DIR="/tmp/${REPO_ORG}/${REPO_NAME}" +REPO_DIR_BASE="/tmp/${REPO_ORG}" ... -Steps 5–11 run in a loop over `TARGET_BRANCHES` — for each branch: -- `git checkout <branch>` and `git pull` to ensure it is up to date -- Apply fix and create PR targeting that branch (from fork if no direct push access) +Steps 5–11 run independently per `TARGET_BRANCH` — for each branch: +- Create branch-specific workspace: `REPO_DIR="${REPO_DIR_BASE}/${REPO_NAME}-${TARGET_BRANCH}"` +- Clone/fetch in that workspace +- Checkout the target branch in that workspace +- Apply fix, run tests, and create PR for that target branch onlyAlso applies to: 239-243, 246-258
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 206 - 207, The workflow currently sets a single REPO_DIR and then iterates branches using checkout loops, which causes state leakage; modify the flow so each target branch performs an independent clone into its own temporary directory (create a fresh REPO_DIR per-target inside the per-target loop), perform git checkout, run the fix/test/PR sequence, and then clean up that temp clone; update mentions of REPO_DIR, the per-target loop, and any checkout logic to reflect per-target isolated clone→checkout→fix→test→PR execution and ensure cleanup after each target.
174-178:⚠️ Potential issue | 🟠 MajorBranch naming guidance is still inconsistent with canonical naming section.
These lines correctly include
<target-branch>in examples, but the canonical pattern later still omits it (fix/cve-...-<package>-attempt-1), which can collide across bases.Suggested doc fix
-- Use consistent naming: `fix/cve-YYYY-XXXXX-<package-name>-attempt-1` +- Use consistent naming: `fix/cve-YYYY-XXXXX-<package-name>-<target-branch>-attempt-1`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 174 - 178, Update the canonical branch-naming pattern to include the <target-branch> token so it matches the earlier examples; specifically change the canonical example `fix/cve-...-<package>-attempt-1` to the consistent pattern used above `fix/cve-YYYY-XXXXX-<package>-<target-branch>-attempt-1` (or equivalent ordering used in the Multi-repo + multi-branch examples) and update any other occurrences in the document so all examples and the canonical section use the same `<target-branch>`-inclusive format to avoid cross-branch collisions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 153-160: The TARGET_BRANCHES assignment can produce duplicates
when ACTIVE_RELEASE_BRANCHES includes DEFAULT_BRANCH; update the logic that
builds TARGET_BRANCHES (the block using REPO_TYPE, DEFAULT_BRANCH and
ACTIVE_RELEASE_BRANCHES) to deduplicate entries before further processing — for
example, after composing TARGET_BRANCHES, iterate and rebuild a new array using
a seen set (declare -A seen) to skip already-added branch names so each branch
appears only once; ensure downstream consumers of TARGET_BRANCHES use the
deduplicated array.
- Around line 162-173: The fenced code block for the "llm-d inference-scheduler"
example is missing a language identifier and blank-line framing; update the
markdown by adding a blank line before and after the triple-backtick fence and
include a language token (e.g., "text") after the opening ``` so the block
around the "upstream llm-d/llm-d-inference-scheduler ..." example is fenced as
```text ... ``` to satisfy MD031/MD040.
- Around line 206-207: The workflow currently sets a single REPO_DIR and then
iterates branches using checkout loops, which causes state leakage; modify the
flow so each target branch performs an independent clone into its own temporary
directory (create a fresh REPO_DIR per-target inside the per-target loop),
perform git checkout, run the fix/test/PR sequence, and then clean up that temp
clone; update mentions of REPO_DIR, the per-target loop, and any checkout logic
to reflect per-target isolated clone→checkout→fix→test→PR execution and ensure
cleanup after each target.
- Around line 174-178: Update the canonical branch-naming pattern to include the
<target-branch> token so it matches the earlier examples; specifically change
the canonical example `fix/cve-...-<package>-attempt-1` to the consistent
pattern used above `fix/cve-YYYY-XXXXX-<package>-<target-branch>-attempt-1` (or
equivalent ordering used in the Multi-repo + multi-branch examples) and update
any other occurrences in the document so all examples and the canonical section
use the same `<target-branch>`-inclusive format to avoid cross-branch
collisions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c2120c28-59ea-4e75-8e7d-6748971ae08e
📒 Files selected for processing (1)
workflows/cve-fixer/.claude/commands/cve.fix.md
cve.fix: when both scan and package check find no CVE evidence: - Auto-determine VEX justification where possible: 1. Component not Present — package not in any manifest (auto) 2. Vulnerable Code not Present — package at safe version (auto) 3. Vulnerable Code not in Execute Path — govulncheck call graph (auto, Go only) 4. Vulnerable Code cannot be Controlled by Adversary — human judgment 5. Inline Mitigations already Exist — human judgment - For cases 1-3: add Jira comment with justification + evidence, do not auto-close - For cases 4-5: log in artifacts/vex-needs-human-review-CVE-*.md, skip Jira comment - In interactive mode: prompt user to select from all 5 options cve.find: add --ignore-vex flag to exclude issues already closed with VEX justification (Not a Bug / Obsolete / Won't Fix) Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
workflows/cve-fixer/.claude/commands/cve.find.md (1)
36-46:⚠️ Potential issue | 🟠 MajorPersist
--ignore-vexas a boolean alongside--ignore-resolved.Step 1 introduces
--ignore-vex, but the storage note still only documents--ignore-resolved. That leaves Step 3’sIGNORE_VEXbranch under-specified.Suggested doc patch
- - Store the `--ignore-resolved` flag as a boolean for use in step 3 + - Store `--ignore-resolved` and `--ignore-vex` flags as booleans for use in step 3🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.find.md` around lines 36 - 46, The docs mention the --ignore-vex flag but never instruct storing it; update the behavior notes so --ignore-vex is persisted as a boolean just like --ignore-resolved (e.g., document IGNORE_VEX alongside IGNORE_RESOLVED), and clarify Step 3’s IGNORE_VEX branch to read that boolean when filtering results; ensure the instruction still forbids using AskUserQuestion or presenting options and that component prompting remains unchanged.
♻️ Duplicate comments (6)
workflows/cve-fixer/.claude/commands/cve.find.md (2)
72-76:⚠️ Potential issue | 🟡 MinorFix MD031 fenced-block spacing in changed list items.
The fenced
bashblocks here still need blank lines before/after to satisfy markdownlint.Also applies to: 84-89
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.find.md` around lines 72 - 76, Add a blank line before and after each fenced bash code block that contains the export lines (the block starting with the URL "https://id.atlassian.com/manage-profile/security/api-tokens" and the block with "export JIRA_API_TOKEN" / "export JIRA_EMAIL") so the fenced blocks have an empty line above and below to satisfy MD031; update both occurrences (the block containing the export lines and the later duplicate block) accordingly.
62-78:⚠️ Potential issue | 🟠 MajorAuth probe logic for
/myselfis still inconsistent and retry is undocumented in command behavior.This block still treats HTTP 403 separately and says “retry once” without curl retry flags. Either consolidate 401 handling for
/myself, or switch endpoint if you need permission-specific branching.Suggested doc patch
TEST_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X GET \ --connect-timeout 10 --max-time 15 \ + --retry 1 --retry-delay 2 --retry-connrefused \ -H "Authorization: Basic ${AUTH}" \ -H "Content-Type: application/json" \ "${JIRA_BASE_URL}/rest/api/3/myself") @@ - - **HTTP 403** → token valid but insufficient permissions — inform user - - **Other / timeout** → network issue — inform user and retry once + - **Other / timeout** → network issue — inform user (probe includes one retry)For Jira Cloud REST API v3, what are the documented response codes for GET /rest/api/3/myself, specifically whether 403 is expected versus 401 for auth/access failures?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.find.md` around lines 62 - 78, The auth probe using GET "${JIRA_BASE_URL}/rest/api/3/myself" is inconsistent: it documents a special HTTP 403 case and “retry once” but the curl invocation (TEST_RESPONSE) has no retry behavior and the endpoint may not reliably differentiate 401 vs 403 for auth issues; update the logic around TEST_RESPONSE to either consolidate 401/403 handling for auth failures or switch to a permission-specific endpoint if you need to detect permission vs credential problems, and explicitly implement a single retry (using curl retry flags or a coded retry loop) when handling network/timeout responses so the documented “retry once” matches actual behavior; ensure messages reference TEST_RESPONSE and the "/rest/api/3/myself" probe so maintainers can find and update the probe logic.workflows/cve-fixer/.claude/commands/cve.fix.md (4)
239-258:⚠️ Potential issue | 🟠 Major“Clone once + branch loop” conflicts with independent branch execution.
This section still describes shared workspace iteration, which can leak state between branch runs and contradicts the per-target independent cycle.
Suggested doc patch
- Steps 5–11 run in a loop over `TARGET_BRANCHES` — for each branch: - - `git checkout <branch>` and `git pull` to ensure it is up to date - - Apply fix and create PR targeting that branch (from fork if no direct push access) + Steps 5–11 run independently per `TARGET_BRANCH` in isolated workspaces: + - Create branch-specific clone dir (e.g., `/tmp/${REPO_ORG}/${REPO_NAME}-${TARGET_BRANCH}`) + - Checkout target branch in that clone, apply fix, test, and create PR + - Do not reuse working tree state across target branches🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 239 - 258, The documentation section "4.3: Branch loop" currently describes a single cloned workspace iterating over TARGET_BRANCHES and may leak state; update the text to reflect the intended independent-per-branch execution model by removing or clarifying the "Clone once" example and the shared workspace loop (steps 5–11) and instead describe that each TARGET_BRANCH run should perform its own checkout/pull/apply-create-PR cycle in an isolated workspace (or explicitly document the alternative "clone once" mode as a separate, stateful option), referencing the TARGET_BRANCHES loop and the checkout/pull/apply PR steps to ensure readers know to avoid shared-state side effects between branch runs.
174-178:⚠️ Potential issue | 🟠 MajorMake branch naming rule consistent with multi-branch behavior.
This section requires branch-qualified fix names, but the canonical rule later (Line 573) still omits
<target-branch>, which can collide across base branches.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 174 - 178, The branch naming guidance is inconsistent: the multi-branch section requires branch-qualified names (example `fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1`) but the canonical naming rule later omits the `<target-branch>` component, risking name collisions; update the canonical rule to include `<target-branch>` (or a `<base-branch>` token) so it matches the multi-branch example and ensure all references to the canonical rule and examples use the same format including the branch qualifier.
153-160:⚠️ Potential issue | 🟠 MajorDeduplicate
TARGET_BRANCHESto prevent duplicate PR attempts.If
ACTIVE_RELEASE_BRANCHEScontainsDEFAULT_BRANCH, this creates duplicate targets.Suggested doc patch
if [ "$REPO_TYPE" = "downstream" ]; then TARGET_BRANCHES=("$DEFAULT_BRANCH" "${ACTIVE_RELEASE_BRANCHES[@]}") else TARGET_BRANCHES=("$DEFAULT_BRANCH") fi + +# Deduplicate while preserving order +UNIQUE_TARGET_BRANCHES=() +for b in "${TARGET_BRANCHES[@]}"; do + [ -z "$b" ] && continue + [[ " ${UNIQUE_TARGET_BRANCHES[*]} " == *" $b "* ]] || UNIQUE_TARGET_BRANCHES+=("$b") +done +TARGET_BRANCHES=("${UNIQUE_TARGET_BRANCHES[@]}")🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 153 - 160, The TARGET_BRANCHES assignment can yield duplicates when ACTIVE_RELEASE_BRANCHES contains DEFAULT_BRANCH; update the logic that builds TARGET_BRANCHES (the branch selection block using TARGET_BRANCHES, DEFAULT_BRANCH, and ACTIVE_RELEASE_BRANCHES) to deduplicate entries before using them — for example, after composing the array, filter it to unique values (using an associative "seen" map loop or a stdout-unique transform like sort -u/awk) and reassign the cleaned list back to TARGET_BRANCHES so no duplicate PR targets are attempted.
163-172:⚠️ Potential issue | 🟡 MinorFix markdown fences (MD031/MD040) in changed examples.
These blocks still need language tags and blank-line framing around fenced blocks.
Also applies to: 473-481
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 163 - 172, The fenced code examples lack language tags and surrounding blank lines, which triggers MD031/MD040; update each triple-backtick block (e.g., the block starting with "upstream llm-d/llm-d-inference-scheduler → PR against: main" and the other occurrence around the content referenced as 473-481) to add an appropriate language tag (like ```text or ```bash) immediately after the opening backticks and ensure there is a blank line before and after the fenced block so the markdown linter accepts the examples; apply this change consistently to all similar fenced blocks in the document.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 439-443: Update the output/reporting docs to reference the new VEX
artifact names and flows instead of the old "already-fixed" wording: replace
references to `artifacts/cve-fixer/fixes/vex-justified-CVE-YYYY-XXXXX.md` and
any mentions of the old “already-fixed” flow with the corresponding new artifact
names (`vex-justified-*`, `vex-needs-human-review-*`) and update the
printed/report messages (e.g., the "✅ CVE-YYYY-XXXXX not present..." line) and
the bullet list for the auto-determined justification cases to explicitly
document writing the correct VEX artifact and leaving closure to a human
reviewer.
---
Outside diff comments:
In `@workflows/cve-fixer/.claude/commands/cve.find.md`:
- Around line 36-46: The docs mention the --ignore-vex flag but never instruct
storing it; update the behavior notes so --ignore-vex is persisted as a boolean
just like --ignore-resolved (e.g., document IGNORE_VEX alongside
IGNORE_RESOLVED), and clarify Step 3’s IGNORE_VEX branch to read that boolean
when filtering results; ensure the instruction still forbids using
AskUserQuestion or presenting options and that component prompting remains
unchanged.
---
Duplicate comments:
In `@workflows/cve-fixer/.claude/commands/cve.find.md`:
- Around line 72-76: Add a blank line before and after each fenced bash code
block that contains the export lines (the block starting with the URL
"https://id.atlassian.com/manage-profile/security/api-tokens" and the block with
"export JIRA_API_TOKEN" / "export JIRA_EMAIL") so the fenced blocks have an
empty line above and below to satisfy MD031; update both occurrences (the block
containing the export lines and the later duplicate block) accordingly.
- Around line 62-78: The auth probe using GET
"${JIRA_BASE_URL}/rest/api/3/myself" is inconsistent: it documents a special
HTTP 403 case and “retry once” but the curl invocation (TEST_RESPONSE) has no
retry behavior and the endpoint may not reliably differentiate 401 vs 403 for
auth issues; update the logic around TEST_RESPONSE to either consolidate 401/403
handling for auth failures or switch to a permission-specific endpoint if you
need to detect permission vs credential problems, and explicitly implement a
single retry (using curl retry flags or a coded retry loop) when handling
network/timeout responses so the documented “retry once” matches actual
behavior; ensure messages reference TEST_RESPONSE and the "/rest/api/3/myself"
probe so maintainers can find and update the probe logic.
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 239-258: The documentation section "4.3: Branch loop" currently
describes a single cloned workspace iterating over TARGET_BRANCHES and may leak
state; update the text to reflect the intended independent-per-branch execution
model by removing or clarifying the "Clone once" example and the shared
workspace loop (steps 5–11) and instead describe that each TARGET_BRANCH run
should perform its own checkout/pull/apply-create-PR cycle in an isolated
workspace (or explicitly document the alternative "clone once" mode as a
separate, stateful option), referencing the TARGET_BRANCHES loop and the
checkout/pull/apply PR steps to ensure readers know to avoid shared-state side
effects between branch runs.
- Around line 174-178: The branch naming guidance is inconsistent: the
multi-branch section requires branch-qualified names (example
`fix/cve-YYYY-XXXXX-<package>-rhoai-3.4-attempt-1`) but the canonical naming
rule later omits the `<target-branch>` component, risking name collisions;
update the canonical rule to include `<target-branch>` (or a `<base-branch>`
token) so it matches the multi-branch example and ensure all references to the
canonical rule and examples use the same format including the branch qualifier.
- Around line 153-160: The TARGET_BRANCHES assignment can yield duplicates when
ACTIVE_RELEASE_BRANCHES contains DEFAULT_BRANCH; update the logic that builds
TARGET_BRANCHES (the branch selection block using TARGET_BRANCHES,
DEFAULT_BRANCH, and ACTIVE_RELEASE_BRANCHES) to deduplicate entries before using
them — for example, after composing the array, filter it to unique values (using
an associative "seen" map loop or a stdout-unique transform like sort -u/awk)
and reassign the cleaned list back to TARGET_BRANCHES so no duplicate PR targets
are attempted.
- Around line 163-172: The fenced code examples lack language tags and
surrounding blank lines, which triggers MD031/MD040; update each triple-backtick
block (e.g., the block starting with "upstream llm-d/llm-d-inference-scheduler
→ PR against: main" and the other occurrence around the content referenced as
473-481) to add an appropriate language tag (like ```text or ```bash)
immediately after the opening backticks and ensure there is a blank line before
and after the fenced block so the markdown linter accepts the examples; apply
this change consistently to all similar fenced blocks in the document.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4dda33f7-a5a1-4ee0-a166-ae7ab194816a
📒 Files selected for processing (2)
workflows/cve-fixer/.claude/commands/cve.find.mdworkflows/cve-fixer/.claude/commands/cve.fix.md
Comment on lines
+439
to
+443
| **If justification auto-determined (cases 1, 2, 3):** | ||
| - Add a comment to the Jira issue with the justification and evidence | ||
| - Do NOT auto-close the issue — leave closing to the human reviewer | ||
| - Document in `artifacts/cve-fixer/fixes/vex-justified-CVE-YYYY-XXXXX.md` | ||
| - Print: "✅ CVE-YYYY-XXXXX not present in [repo]. VEX justification added to [JIRA-KEY]: [justification]" |
There was a problem hiding this comment.
Output/reporting docs need alignment with new VEX artifacts.
You now define vex-justified-*/vex-needs-human-review-*, but output sections still describe the old “already-fixed” flow as the primary non-PR artifact path. Please align artifact documentation to avoid operator confusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 439 - 443,
Update the output/reporting docs to reference the new VEX artifact names and
flows instead of the old "already-fixed" wording: replace references to
`artifacts/cve-fixer/fixes/vex-justified-CVE-YYYY-XXXXX.md` and any mentions of
the old “already-fixed” flow with the corresponding new artifact names
(`vex-justified-*`, `vex-needs-human-review-*`) and update the printed/report
messages (e.g., the "✅ CVE-YYYY-XXXXX not present..." line) and the bullet list
for the auto-determined justification cases to explicitly document writing the
correct VEX artifact and leaving closure to a human reviewer.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Updates
cve.fixto target branches differently based onrepo_type:default_branchonly (e.g.main)default_branch+ each branch inactive_release_branchesEach branch gets its own independent clone → fix → test → PR cycle. Branches are never combined into a single PR.
Example for
red-hat-data-services/llm-d-inference-schedulerwith active branchesrhoai-3.3,rhoai-3.4,rhoai-3.4-ea.1,rhoai-3.4-ea.2:mainrhoai-3.3rhoai-3.4rhoai-3.4-ea.1rhoai-3.4-ea.2No mapping file changes required — logic is derived from existing
repo_type,default_branch, andactive_release_branchesfields.Test plan
/cve.fix llm-dwith an inference-scheduler CVE — verify upstream gets 1 PR (main only) and downstream gets 5 PRs (main + 4 release branches)fix/cve-YYYY-XXXXX-urllib3-rhoai-3.4-attempt-1)🤖 Generated with Claude Code