feat(RELEASE-2475): add close_advisory_issues.py script by johnbieren · Pull Request #864 · konflux-ci/release-service-utils

johnbieren · 2026-06-30T18:59:57Z

This commit adds a python script to replicate the functionality of the inline bash script in the close-advisory-issues managed task in the catalog repo. The task will be updated to use this python module instead.

Assisted-By: Cursor

codecov-commenter · 2026-06-30T19:04:24Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.72%. Comparing base (586cbe7) to head (0e458d9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #864      +/-   ##
==========================================
+ Coverage   95.63%   95.72%   +0.09%     
==========================================
  Files          71       72       +1     
  Lines        7078     7231     +153     
==========================================
+ Hits         6769     6922     +153     
  Misses        309      309

Flag	Coverage Δ
unit-tests	`95.72% <100.00%> (+0.09%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ipts/python/tasks/managed/close_advisory_issues.py	`100.00% <100.00%> (ø)`

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 586cbe7...0e458d9. Read the comment docs.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

johnbieren · 2026-06-30T19:27:09Z

/agentic_review

johnbieren · 2026-06-30T19:32:50Z

/agentic_review

qodo-app-for-konflux-ci · 2026-06-30T19:47:12Z

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (5) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 25 rules

1. Whitespace breaks source matching 🐞 Bug ≡ Correctness

Description

is_jira_eligible_issue() strips issue['source'] before normalizing, but process_fixed_issue()
passes the unstripped value into normalize_issue_server(). A fixed issue with a whitespace-padded
supported source (e.g., "issues.redhat.com ") can therefore pass the Jira-eligibility gate, yet
later be skipped as “unsupported” and never closed/commented.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R203-205]
+    server = normalize_issue_server(source)
+    if server != SUPPORTED_JIRA_SERVER:
+        logger.warning(

Relevance

⭐⭐⭐ High
Team previously flagged/handled whitespace normalization in inputs (e.g., PR #831 trims args; PR
#813 strip-before-mapping suggestion).
PR-#831
PR-#813

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The eligibility check strips source before normalization, but the processing function does not,
and then relies on exact string equality for server support. Since close_advisory_issues() uses
the eligibility check to decide whether to do Jira setup and then processes the original issues
list, the mismatch can lead to eligible-looking input being skipped at runtime.
scripts/python/tasks/managed/close_advisory_issues.py[47-58]
scripts/python/tasks/managed/close_advisory_issues.py[186-212]
scripts/python/tasks/managed/close_advisory_issues.py[263-299]
scripts/python/tasks/managed/close_advisory_issues.py[40-44]

Agent prompt

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

## Issue description
`process_fixed_issue()` uses `normalize_issue_server(source)` without trimming whitespace, while eligibility (`is_jira_eligible_issue`) trims first. This inconsistency can cause a supported Jira issue entry to be skipped during processing if `source` has surrounding whitespace.

## Issue Context
- Eligibility path: `source.strip()` is applied before normalization.
- Processing path: `source` is validated for non-blank, but not stripped before normalization.
- `normalize_issue_server()` only maps an exact hostname match, so whitespace changes behavior.

## Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[47-58]
- scripts/python/tasks/managed/close_advisory_issues.py[186-212]

### Suggested change
In `process_fixed_issue()`, strip `source` once (e.g., `normalized_source = source.strip()`) and use that for `normalize_issue_server(...)` and logging. Optionally deduplicate by reusing `is_jira_eligible_issue()` or centralizing the normalization/validation logic to prevent future drift.

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

2. test_close_advisory_issues docstring non-imperative 📘 Rule violation ⚙ Maintainability

Description

The test module’s docstring starts with Tests, which is not an imperative verb form as required.
This reduces docstring consistency across the codebase.

Code

scripts/python/tasks/managed/test_close_advisory_issues.py[1]
+"""Tests for `close_advisory_issues` task logic."""

Relevance

⭐⭐⭐ High
Imperative docstring style enforced; tests use “Test …” module docstring in merged PR #837.
PR-#837

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 914 requires module docstrings to be triple-double-quoted and begin with an
imperative verb. The new module docstring begins with Tests.
Rule 914: Require docstrings for modules and public functions in triple-double-quote imperative format
scripts/python/tasks/managed/test_close_advisory_issues.py[1-1]

Agent prompt

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

## Issue description
Module-level docstrings must start with an imperative verb. The test module docstring currently begins with `Tests`, which is not in the required imperative form.

## Issue Context
This rule applies to added/modified Python modules, including test modules; only test *functions* are exempt.

## Fix Focus Areas
- scripts/python/tasks/managed/test_close_advisory_issues.py[1-1]

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

3. No retry on 429 🐞 Bug ☼ Reliability

Description

close_advisory_issues() builds a retry-enabled Session without including HTTP 429 in the retryable
status codes, so Jira rate-limit responses will raise immediately and can make the task flaky under
load. This diverges from the repo’s standard HTTP GET helper which implements explicit 429 backoff.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R285-291]

+    session = http_client.get_retry_session(
+        total=3,
+        connect=3,
+        read=3,
+        status=2,
+        allowed_methods=frozenset({"GET", "POST"}),
+    )

Relevance

⭐⭐ Medium
Repo added explicit 429 backoff in http_client.get_text (PR #813), but no clear precedent for
status_forcelist 429 usage.
PR-#813

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The task’s session creation does not pass status_forcelist, so it inherits
http_client.get_retry_session() defaults (500/502/503/504 only). The Jira request helpers then
call raise_for_status(), so a 429 will error without retry. In contrast, http_client.get_text()
contains explicit 429 retry/backoff logic, showing 429 handling is a supported/expected pattern in
this repo.
scripts/python/tasks/managed/close_advisory_issues.py[285-291]
scripts/python/tasks/managed/close_advisory_issues.py[101-113]
scripts/python/helpers/http_client.py[28-56]
scripts/python/helpers/http_client.py[64-130]

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 Jira workflow creates a retry-enabled requests `Session` via `http_client.get_retry_session(...)` but does not configure it to retry HTTP 429 responses. Because `jira_get_json()`/`jira_post_json()` call `raise_for_status()`, a 429 response will fail the request immediately rather than backing off.

## Issue Context
The shared helper `http_client.get_text()` has dedicated logic to retry 429 with exponential backoff, indicating 429 handling is an expected reliability behavior in this codebase.

## Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[285-291]

## Proposed fix
Pass an explicit `status_forcelist` that includes 429 when creating the retry session, e.g.:

```python
session = http_client.get_retry_session(
   total=3,
   connect=3,
   read=3,
   status=2,
   status_forcelist=(429, 500, 502, 503, 504),
   allowed_methods=frozenset({"GET", "POST"}),
)
```

(Alternatively, implement explicit 429 backoff similar to `http_client.get_text()` if you need different semantics than urllib3’s `Retry` for rate limits.)

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

View more (2)

4. Unneeded Jira secret requirement 🐞 Bug ☼ Reliability

Description

close_advisory_issues() always reads Jira credentials and creates a retry session even when there
are no fixed issues (or only unsupported trackers), so the task can fail just because the Jira
secret is missing despite having no Jira work to do.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R255-266]

+    logger.info("Loading release data from %s", data_file)
+    data = file.load_json_dict(data_file)
+    fixed_issues = load_fixed_issues(data)
+    email, token = read_jira_credentials(secret_path)
+    auth = HTTPBasicAuth(email, token)
+    session = http_client.get_retry_session(
+        total=3,
+        connect=3,
+        read=3,
+        status=2,
+        allowed_methods=frozenset({"GET", "POST"}),
+    )

Relevance

⭐⭐ Medium
Reliability suggestions exist (#810) but no precedent about deferring secret reads when no Jira
work.
PR-#810

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The task reads Jira credentials and creates a retry session before iterating issues, even though
process_fixed_issue() may skip all issues (e.g., non-Jira sources). Because mounted secret reads
are direct filesystem reads, missing secrets will raise and fail the run even when there are zero
Jira actions required.
scripts/python/tasks/managed/close_advisory_issues.py[255-266]
scripts/python/tasks/managed/close_advisory_issues.py[191-201]
schemas/dataKeys.json[232-250]
scripts/python/helpers/authentication.py[25-33]
scripts/python/tasks/managed/test_close_advisory_issues.py[189-207]

Agent prompt

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

### Issue description
`close_advisory_issues()` unconditionally reads the Jira secret and initializes an authenticated HTTP session even when `fixed_issues` is empty or contains only unsupported trackers. This can cause no-op runs to fail if the Jira secret is not mounted.

### Issue Context
- The data schema allows `releaseNotes.issues.fixed[].source` to be non-Jira (e.g., Bugzilla).
- `process_fixed_issue()` already skips unsupported trackers, so a run can legitimately do zero Jira calls.

### Fix approach
- Defer `read_jira_credentials()` + `HTTPBasicAuth` + `get_retry_session()` until you know there is at least one Jira-eligible issue to process.
 - Option A: pre-filter `fixed_issues` for Jira-eligible entries (validate `id`/`source`, normalize server, check supported).
 - Option B: lazy-initialize `auth`/`session` on first eligible issue during iteration.
- Update/adjust the unit test that currently asserts a session is always created on no-issue runs.

### Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[242-275]
- scripts/python/tasks/managed/test_close_advisory_issues.py[189-207]

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

5. Unescaped issue id in URL 🐞 Bug ⛨ Security

Description

jira_issue_url() interpolates issue_id directly into the URL path without escaping/validation, so a
malformed releaseNotes.issues.fixed[].id containing '/' or '?' can change the requested Jira REST
path on the fixed Jira host while using privileged credentials.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R83-87]

+def jira_issue_url(server: str, issue_id: str) -> str:
+    """Build the Jira issue API URL for *issue_id* on *server*."""
+    api_path = api_path_for_server(server)
+    return f"https://{server}/{api_path}/{issue_id}"
+

Relevance

⭐⭐ Medium
Only similar prior suggestion was path sanitization (#795); no clear accept/reject precedent for
URL-path escaping.
PR-#795

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The code takes issue_id from the release data and only checks it is a non-empty string; that
untrusted string is then concatenated into the Jira URL path. While the host is constrained to
redhat.atlassian.net, the path is not, enabling requests to unintended Jira endpoints on that
host.
scripts/python/tasks/managed/close_advisory_issues.py[83-87]
scripts/python/tasks/managed/close_advisory_issues.py[182-203]
scripts/python/tasks/managed/close_advisory_issues.py[44-47]
schemas/dataKeys.json[232-250]

Agent prompt

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

### Issue description
`jira_issue_url()` builds URLs via string concatenation and includes `issue_id` verbatim. A malformed `id` (e.g. containing `/`, `..`, `?`) can alter the REST path requested on `redhat.atlassian.net`.

### Issue Context
- The Jira host is fixed by `is_supported_jira_server()`, so this is not arbitrary-host SSRF; it is path manipulation against the Jira origin.
- The schema only constrains `id` to be a string (no pattern), so validation belongs in this task.

### Fix approach
- Prefer strict validation for allowed Jira identifiers (e.g., `ABC-123` and/or numeric ids) and skip+warn on invalid ids.
 - Alternatively (or additionally), URL-escape the path segment (e.g., `urllib.parse.quote(issue_id, safe='')`).
- Add a unit test covering an invalid `issue_id` containing `/` or `?` to ensure it is rejected or safely encoded.

### Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[83-87]
- scripts/python/tasks/managed/close_advisory_issues.py[174-206]
- scripts/python/tasks/managed/test_close_advisory_issues.py[258-266]

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

6. Docstring precedes __future__ import 📘 Rule violation ⚙ Maintainability ⭐ New

Description

from __future__ import annotations is not the first non-shebang, non-encoding, non-comment line
because a module docstring appears before it in both the main module and its test. This violates the
project requirement (Compliance ID 902) for consistent postponed-annotations imports and may cause
style/consistency checks to fail.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R2-5]
+"""Close Jira issues listed in releaseNotes after an advisory is published."""
+
+from __future__ import annotations
+

Relevance

⭐ Low
Repo scripts commonly place module docstring before from __future__ import annotations (e.g., PR
#817), so not enforced.
PR-#817

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 902 requires the first non-shebang/non-encoding/non-comment line to be exactly `from
__future__ import annotations. In scripts/python/tasks/managed/close_advisory_issues.py`, the
module docstring is placed before the future import, so the import is not first; similarly, in
scripts/python/tasks/managed/test_close_advisory_issues.py, the docstring is on line 1 and the
future import on line 3, so the future import is also not the first applicable line.

Rule 902: Always import postponed annotations in Python modules
scripts/python/tasks/managed/close_advisory_issues.py[2-5]
scripts/python/tasks/managed/test_close_advisory_issues.py[1-4]

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 modules violate the rule requiring `from __future__ import annotations` to be the first non-shebang/non-encoding/non-comment line because a module docstring precedes it.

## Issue Context
Compliance ID 902 requires the postponed-annotations future import to be the first statement (after optional shebang/encoding) and enforces this strict ordering across all Python modules, including tests. Update the file header ordering to satisfy this requirement.

## Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[2-5]
- scripts/python/tasks/managed/test_close_advisory_issues.py[1-4]

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

7. Uncaught Jira lookup aborts 🐞 Bug ☼ Reliability ⭐ New

Description

process_fixed_issue() performs the initial Jira GET (jira_get_json(issue_url)) outside the
RequestException handler, so any timeout/HTTP error will raise and abort close_advisory_issues()
mid-loop, leaving subsequent fixed issues unprocessed.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R224-231]

+    issue_url = jira_issue_url(server, normalized_id)
+    comment = close_comment(advisory_url)
+
+    issue_data = jira_get_json(session, issue_url, auth)
+    if issue_status_name(issue_data) == "Closed":
+        logger.info("Issue %s is already in Closed state. Skipping it.", issue)
+        return
+

Relevance

⭐ Low
Managed tasks policy is to let exceptions propagate; reviewers even requested removing broad
try/except (PR #841, #823).
PR-#841
PR-#823

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
jira_get_json() raises for non-2xx responses and request failures; process_fixed_issue() invokes
jira_get_json() for the issue lookup outside its try/except, and close_advisory_issues() does not
catch exceptions around the per-issue loop, so one lookup failure stops processing remaining issues.
scripts/python/tasks/managed/close_advisory_issues.py[101-113]
scripts/python/tasks/managed/close_advisory_issues.py[224-263]
scripts/python/tasks/managed/close_advisory_issues.py[264-302]

Agent prompt

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

### Issue description
`process_fixed_issue()` calls `jira_get_json(session, issue_url, auth)` before entering its `try/except requests.RequestException` block. Because `jira_get_json()` can raise (network error, non-2xx via `raise_for_status()`, etc.), a single failing issue lookup will raise out of `process_fixed_issue()` and abort the whole `close_advisory_issues()` loop.

### Issue Context
The rest of the function is written as best-effort (it catches close-transition failures and falls back to commenting). The initial lookup should follow the same best-effort behavior so one bad Jira issue does not prevent processing other issues.

### Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[101-113]
- scripts/python/tasks/managed/close_advisory_issues.py[186-263]
- scripts/python/tasks/managed/close_advisory_issues.py[264-302]

### Suggested fix
Either (or both):
1. Wrap the initial `issue_data = jira_get_json(...)` in a `try/except requests.RequestException` (and optionally `ValueError`) and on failure `logger.warning(...)` and `return` to continue with the next issue.
2. Additionally, defensively wrap the per-issue call site in `close_advisory_issues()`:
  ```py
  for issue in fixed_issues:
      try:
          process_fixed_issue(...)
      except requests.RequestException as exc:
          logger.warning("Warning: failed processing issue %s: %s", issue, exc)
  ```
  This ensures any unexpected per-issue failure cannot terminate the whole run.

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

8. Expected failures not CheckStepError 📘 Rule violation ≡ Correctness

Description

In this managed Tekton task, expected failure conditions raise generic exceptions (e.g.,
FileNotFoundError, ValueError) instead of tekton.CheckStepError. This can make step-failure
signaling inconsistent with the project standard for Tekton steps.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R272-276]

+    data_file = data_dir / data_path
+    if not data_file.is_file():
+        msg = "No data JSON was provided."
+        raise FileNotFoundError(msg)
+

Relevance

⭐ Low
Repo policy for managed tasks is to let exceptions propagate (PR #841); no evidence they require
CheckStepError here.
PR-#841
PR-#813

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 904 requires Tekton step failures to be signaled using tekton.CheckStepError for
expected failure paths. The new script raises ValueError for missing Jira secret fields and
FileNotFoundError when the data file is absent, both of which are expected operational failure
cases in this step.
Rule 904: Use helpers.tekton.CheckStepError for Tekton step failures
scripts/python/tasks/managed/close_advisory_issues.py[85-92]
scripts/python/tasks/managed/close_advisory_issues.py[272-276]

Agent prompt

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

## Issue description
Expected/valid step-failure conditions in this Tekton managed task are currently raised as generic exceptions (e.g., `FileNotFoundError`, `ValueError`). Per compliance, step failure should be signaled using `helpers.tekton.CheckStepError` (imported here as `tekton.CheckStepError`) for normal/expected failure cases.

## Issue Context
This script runs as a Tekton step entrypoint (`scripts/python/tasks/managed/...`). When required inputs like the release data file or Jira credentials are missing/invalid, that is an expected operational failure and should use `tekton.CheckStepError`.

## Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[85-92]
- scripts/python/tasks/managed/close_advisory_issues.py[272-276]

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

View more (2)

9. close_advisory_issues lacks dependency injection 📘 Rule violation ▣ Testability

Description

close_advisory_issues() performs file I/O and HTTP session creation using concrete imports
(file.load_json_dict, http_client.get_retry_session) without overridable callable keyword
arguments. This makes behavior harder to test and violates the dependency injection requirement for
side-effectful operations.

Code

scripts/python/tasks/managed/close_advisory_issues.py[R264-292]

+def close_advisory_issues(
+    *,
+    data_dir: Path,
+    data_path: Path,
+    advisory_url: str,
+    secret_path: Path,
+) -> None:
+    """Close fixed Jira issues referenced in the release data file."""
+    data_file = data_dir / data_path
+    if not data_file.is_file():
+        msg = "No data JSON was provided."
+        raise FileNotFoundError(msg)
+
+    logger.info("Loading release data from %s", data_file)
+    data = file.load_json_dict(data_file)
+    fixed_issues = load_fixed_issues(data)
+    if not any(is_jira_eligible_issue(issue) for issue in fixed_issues):
+        return
+
+    email, token = read_jira_credentials(secret_path)
+    auth = HTTPBasicAuth(email, token)
+    session = http_client.get_retry_session(
+        total=3,
+        connect=3,
+        read=3,
+        status=2,
+        allowed_methods=frozenset({"GET", "POST"}),
+    )
+

Relevance

⭐ Low
Merged PRs (e.g., #837) keep direct HTTP/file calls; DI-as-callable suggestions appear but weren’t
adopted.
PR-#837

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 906 requires side-effectful/external dependencies to be injected as overridable
callable keyword args with production defaults. close_advisory_issues() directly calls file I/O
and HTTP session creation without providing injectable callables.
Rule 906: Inject dependencies as overridable callable keyword arguments with production-safe defaults
scripts/python/tasks/managed/close_advisory_issues.py[264-292]

Agent prompt

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

## Issue description
`close_advisory_issues()` calls side-effectful dependencies (filesystem reads and HTTP session creation) directly via imported modules. The compliance requirement asks for these to be injected as overridable callable keyword arguments with production-safe defaults.

## Issue Context
This function reads a JSON file and creates a retry session. For unit testing and determinism, these should be passed in as keyword-only callables (e.g., `load_json_fn=...`, `get_session_fn=...`) with defaults set to the current production implementations.

## Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[264-292]

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

10. jira_get_json uses session.get 📘 Rule violation ⚙ Maintainability

Description

jira_get_json() performs a direct HTTP GET via requests.Session.get() instead of using the
shared helpers.http_client.get_text() helper. This bypasses the project-standard HTTP GET wrapper
and may lead to inconsistent behavior (timeouts/retries/auth handling) across tasks.

Code

scripts/python/tasks/managed/close_advisory_issues.py[95]
+    response = session.get(url, auth=auth, timeout=60.0)

Relevance

⭐ Low
Merged code still uses direct session.get despite prior compliance suggestion (#802), indicating
non-enforcement.
PR-#802

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 915 requires all HTTP GET requests to use helpers.http_client.get_text() rather
than calling HTTP client libraries directly. The new code calls session.get(...) in
jira_get_json().
Rule 915: Use helpers.http_client.get_text() for all HTTP GET requests
scripts/python/tasks/managed/close_advisory_issues.py[89-101]

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 managed task performs an HTTP GET using `requests.Session.get()` directly, but the compliance rule requires using `helpers.http_client.get_text()` for all HTTP GET requests.

## Issue Context
The module already imports `http_client` and uses `http_client.get_retry_session()`, but the GET itself is still done via `session.get(...)`. To comply, route GET requests through the shared helper (then parse JSON as needed).

## Fix Focus Areas
- scripts/python/tasks/managed/close_advisory_issues.py[89-101]

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

johnbieren · 2026-06-30T19:56:06Z

/agentic_review

qodo-app-for-konflux-ci · 2026-06-30T20:21:21Z

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

johnbieren · 2026-06-30T20:55:53Z

/agentic_review

qodo-app-for-konflux-ci · 2026-06-30T21:06:10Z

Code review by qodo was updated up to the latest commit 152c3ce

This commit adds a python script to replicate the functionality of the inline bash script in the close-advisory-issues managed task in the catalog repo. The task will be updated to use this python module instead. Assisted-By: Cursor Signed-off-by: Johnny Bieren <jbieren@redhat.com>

johnbieren · 2026-06-30T21:14:14Z

/agentic_review

qodo-app-for-konflux-ci · 2026-06-30T21:22:18Z

Code review by qodo was updated up to the latest commit 0e458d9

github-actions Bot added the ai-assisted label Jun 30, 2026

johnbieren force-pushed the release2475 branch from 0003a08 to 81cd024 Compare June 30, 2026 19:01

qodo-app-for-konflux-ci Bot reviewed Jun 30, 2026

View reviewed changes

Comment thread scripts/python/tasks/managed/test_close_advisory_issues.py Outdated

Comment thread scripts/python/tasks/managed/close_advisory_issues.py

Comment thread scripts/python/tasks/managed/close_advisory_issues.py

johnbieren force-pushed the release2475 branch from 81cd024 to e813053 Compare June 30, 2026 19:55

qodo-app-for-konflux-ci Bot reviewed Jun 30, 2026

View reviewed changes

Comment thread scripts/python/tasks/managed/close_advisory_issues.py Outdated

johnbieren force-pushed the release2475 branch from e813053 to 152c3ce Compare June 30, 2026 20:55

qodo-app-for-konflux-ci Bot reviewed Jun 30, 2026

View reviewed changes

Comment thread scripts/python/tasks/managed/close_advisory_issues.py

johnbieren force-pushed the release2475 branch from 152c3ce to 0e458d9 Compare June 30, 2026 21:14

johnbieren marked this pull request as ready for review July 1, 2026 15:17

release-service-bot assigned elenagerman and querti Jul 1, 2026

querti approved these changes Jul 2, 2026

View reviewed changes

johnbieren added the prod/needs-approval label Jul 2, 2026

johnbieren requested a review from twaugh July 2, 2026 12:24

Uh oh!

Conversation

johnbieren commented Jun 30, 2026

Uh oh!

codecov-commenter commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

johnbieren commented Jun 30, 2026

Uh oh!

johnbieren commented Jun 30, 2026

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

Uh oh!

johnbieren commented Jun 30, 2026

Uh oh!

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026

Uh oh!

johnbieren commented Jun 30, 2026

Uh oh!

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026

Uh oh!

johnbieren commented Jun 30, 2026

Uh oh!

qodo-app-for-konflux-ci Bot commented Jun 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov-commenter commented Jun 30, 2026 •

edited

Loading

qodo-app-for-konflux-ci Bot commented Jun 30, 2026 •

edited

Loading