Skip to content

feat: create separate PRs per branch for downstream repos in cve.fix #101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
vmrh21 wants to merge 5 commits into
base: main
Choose a base branch
from
+286 −81
Open

feat: create separate PRs per branch for downstream repos in cve.fix #101

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
96c3e63
feat: create separate PRs per branch for downstream repos
vmrh21 Apr 2, 2026
340b108
fix: replace env var pre-check with API test call for Jira auth
vmrh21 Apr 5, 2026
177e6d0
fix: improve GitHub auth guidance and add fork fallback for no-write-…
vmrh21 Apr 5, 2026
841df52
feat: add VEX justification support when CVE not found in repo
vmrh21 Apr 6, 2026
60d6f70
feat: add base image detection and FROM line update for base image CVEs
vmrh21 Apr 6, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 35 additions & 47 deletions workflows/cve-fixer/.claude/commands/cve.find.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,8 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
1. **Parse Arguments and Flags**
- Parse the command arguments for the component name, optional subcomponent, and optional flags
- **Supported flags:**
- `--ignore-resolved` — Exclude issues with Jira status "Resolved" from results
- `--ignore-resolved` — Exclude issues with status "Resolved" from results
- `--ignore-vex` — Exclude issues already closed as "Not a Bug" with a VEX justification
- The component name is the first argument that is not a flag
- The subcomponent is the second positional argument that is not a flag (optional)
- If component is not provided, ask the user to type the component name
Expand All @@ -51,59 +52,40 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
/cve.find "AI Evaluations" trustyai-ragas
```

2. **Check JIRA API Token (REQUIRED - User Setup)**
- **This is the ONLY thing the user must configure manually before proceeding**
2. **Verify Jira Access**

- Check if JIRA_API_TOKEN and JIRA_EMAIL are set:
```bash
if [ -z "$JIRA_API_TOKEN" ]; then
echo "ERROR: JIRA_API_TOKEN is not set"
else
echo "JIRA_API_TOKEN is set"
fi
if [ -z "$JIRA_EMAIL" ]; then
echo "ERROR: JIRA_EMAIL is not set"
else
echo "JIRA_EMAIL is set"
fi
```

- **If JIRA_API_TOKEN or JIRA_EMAIL is NOT set or empty**:
- **STOP here and inform the user they need to set up both variables first**
- Provide instructions:

**Step 1: Generate a Jira API Token**
- Go to https://id.atlassian.com/manage-profile/security/api-tokens
- Click "Create API token"
- Give it a name and copy the token

**Step 2: Export both environment variables**
```bash
export JIRA_API_TOKEN="your-token-here"
export JIRA_EMAIL="your-email@redhat.com"
```
To make it persistent, add to `~/.bashrc` or `~/.zshrc`:
```bash
echo 'export JIRA_API_TOKEN="your-token-here"' >> ~/.bashrc
echo 'export JIRA_EMAIL="your-email@redhat.com"' >> ~/.bashrc
source ~/.bashrc
```

- **After user sets the variables, verify they're exported correctly** using the check script above
- Should output: "JIRA_API_TOKEN is set" and "JIRA_EMAIL is set"

- **Only proceed to the next steps if both JIRA_API_TOKEN and JIRA_EMAIL are set**
Secrets may be injected by the Ambient session, a secrets manager, or an MCP server — do NOT rely solely on bash env var checks. Instead, attempt a lightweight test API call and let the response determine whether credentials are available.

```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"
```
Comment on lines +70 to +76
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 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).

- **HTTP 403** → token valid but insufficient permissions — inform user
- **Other / timeout** → network issue — inform user and retry once
Comment on lines +59 to +78
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.


**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).
Comment on lines +59 to +80
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 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:

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).


3. **Query Jira for CVE Issues**

a. Set up variables:
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
Comment on lines +84 to +88
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 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.

```

b. Construct JQL query and execute API call:
Expand Down Expand Up @@ -156,6 +138,12 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
JQL="${JQL} AND status not in (\"Resolved\")"
fi

# Append VEX filter if --ignore-vex flag was provided
# Excludes issues closed as "Not a Bug" (VEX justified) or "Obsolete" or "Won't Fix"
if [ "$IGNORE_VEX" = "true" ]; then
JQL="${JQL} AND NOT (status = \"Closed\" AND resolution in (\"Not a Bug\", \"Obsolete\", \"Won't Fix\"))"
fi

# URL-encode the JQL query for the GET request
ENCODED_JQL=$(python3 -c "import urllib.parse; print(urllib.parse.quote('''${JQL}'''))")

Expand Down
Loading
Loading