Skip to content

Fix extended thinking and allow per-repo context files (AGENTS.md, CLAUDE.md, etc.) to be included as context#2387

Open
avidspartan1 wants to merge 15 commits into
The-PR-Agent:mainfrom
avidspartan1:feat/improvements
Open

Fix extended thinking and allow per-repo context files (AGENTS.md, CLAUDE.md, etc.) to be included as context#2387
avidspartan1 wants to merge 15 commits into
The-PR-Agent:mainfrom
avidspartan1:feat/improvements

Conversation

@avidspartan1

@avidspartan1 avidspartan1 commented May 11, 2026

Copy link
Copy Markdown

User description

Resolves #2357.

I backed out my other PR because it was too many changes (previously included "de-dupe inline comments") in one PR.


PR Type

Enhancement, Bug fix


Description

  • Add support for per-repository context files (AGENTS.md, CLAUDE.md, etc.) included in AI prompts

  • Allow overriding Claude extended thinking models via configuration

  • Support GitHub organization-level global settings repository

  • Implement repo context caching with TTL and size limits

  • Add repo file fetching for Gitea, GitLab, and GitHub providers


Diagram Walkthrough

flowchart LR
  A["Configuration"] -->|repo_context_files| B["Repo Context Builder"]
  B -->|fetch files| C["Git Providers"]
  C -->|AGENTS.md, CLAUDE.md| D["Instruction Files Renderer"]
  D -->|formatted context| E["AI Prompts"]
  F["Claude Models Override"] -->|claude_extended_thinking_models_override| G["LiteLLM Handler"]
  G -->|extended thinking| E
  H["GitHub Org Settings"] -->|global .pr_agent.toml| I["Settings Merger"]
  I -->|merged config| E
Loading

File Walkthrough

Relevant files
Enhancement
15 files
__init__.py
Expand Claude extended thinking model support                       
+10/-1   
litellm_ai_handler.py
Add configurable Claude extended thinking model override 
+16/-2   
repo_context.py
New module for repository context file handling                   
+265/-0 
git_provider.py
Add base method for repository file content retrieval       
+3/-0     
gitea_provider.py
Implement repository file content fetching for Gitea         
+30/-0   
github_provider.py
Add GitHub org-level settings and repo file fetching         
+32/-2   
gitlab_provider.py
Implement repository file content fetching for GitLab       
+13/-3   
utils.py
Support multiple repository settings files with merging   
+29/-10 
pr_code_suggestions.py
Include repository context in code suggestions prompts     
+2/-0     
pr_description.py
Include repository context in description prompts               
+2/-0     
pr_reviewer.py
Include repository context in review prompts                         
+2/-0     
pr_code_suggestions_prompts.toml
Add repository context section to code suggestions template
+9/-0     
pr_code_suggestions_prompts_not_decoupled.toml
Add repository context section to non-decoupled template 
+9/-0     
pr_description_prompts.toml
Add repository context section to description template     
+7/-0     
pr_reviewer_prompts.toml
Add repository context section to review template               
+9/-0     
Configuration changes
1 files
configuration.toml
Add repo context and Claude model override configuration options
+6/-0     
Tests
6 files
test_git_provider_utils.py
Add tests for merged global and local settings                     
+27/-1   
test_gitea_provider.py
Add tests for Gitea repository file content fetching         
+65/-0   
test_github_provider_settings.py
New tests for GitHub org-level settings support                   
+92/-0   
test_gitlab_provider.py
Add tests for GitLab repository file content fetching       
+21/-0   
test_litellm_claude_extended_thinking.py
New tests for Claude extended thinking model override       
+61/-0   
test_repo_context.py
Comprehensive tests for repository context functionality 
+501/-0 
Documentation
2 files
github.md
Document GitHub organization-level settings support           
+2/-0     
configuration_options.md
Document global settings and GitHub Enterprise support     
+2/-0     

@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Support Claude model overrides and repository context files in AI prompts

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Add support for overriding Claude extended thinking models via config
• Include repository context files (AGENTS.md, CLAUDE.md, etc.) in AI prompts
• Extend git provider interface with repo file content retrieval capability
• Add comprehensive tests for new features and fix minor code issues
Diagram
flowchart LR
  A["Config Settings"] -->|claude_extended_thinking_models_override| B["LiteLLM Handler"]
  C["Repo Context Files"] -->|repo_context_files config| D["build_repo_context"]
  D -->|fetches files| E["Git Provider"]
  D -->|renders context| F["Instruction Files"]
  F -->|injected into| G["AI Prompts"]
  B -->|uses models| G
Loading

Grey Divider

File Changes

1. pr_agent/algo/__init__.py ✨ Enhancement +10/-1

Expand Claude extended thinking model list

pr_agent/algo/init.py


2. pr_agent/algo/ai_handlers/litellm_ai_handler.py ✨ Enhancement +16/-2

Add config override for Claude extended thinking models

pr_agent/algo/ai_handlers/litellm_ai_handler.py


3. pr_agent/algo/repo_context.py ✨ Enhancement +64/-0

New module for repository context file handling

pr_agent/algo/repo_context.py


View more (13)
4. pr_agent/git_providers/git_provider.py ✨ Enhancement +3/-0

Add abstract method for repo file content retrieval

pr_agent/git_providers/git_provider.py


5. pr_agent/git_providers/github_provider.py ✨ Enhancement +12/-1

Implement repo file content retrieval for GitHub

pr_agent/git_providers/github_provider.py


6. pr_agent/git_providers/gitlab_provider.py 🐞 Bug fix +2/-3

Remove duplicate file lookup condition

pr_agent/git_providers/gitlab_provider.py


7. pr_agent/tools/pr_code_suggestions.py ✨ Enhancement +3/-1

Integrate repository context into code suggestions

pr_agent/tools/pr_code_suggestions.py


8. pr_agent/tools/pr_description.py ✨ Enhancement +2/-0

Integrate repository context into PR descriptions

pr_agent/tools/pr_description.py


9. pr_agent/tools/pr_reviewer.py ✨ Enhancement +2/-0

Integrate repository context into PR reviews

pr_agent/tools/pr_reviewer.py


10. pr_agent/settings/code_suggestions/pr_code_suggestions_prompts.toml ✨ Enhancement +9/-0

Add repository context section to code suggestions prompt

pr_agent/settings/code_suggestions/pr_code_suggestions_prompts.toml


11. pr_agent/settings/code_suggestions/pr_code_suggestions_prompts_not_decoupled.toml ✨ Enhancement +9/-0

Add repository context section to non-decoupled prompt

pr_agent/settings/code_suggestions/pr_code_suggestions_prompts_not_decoupled.toml


12. pr_agent/settings/configuration.toml ⚙️ Configuration changes +6/-0

Add repo context and Claude override configuration options

pr_agent/settings/configuration.toml


13. pr_agent/settings/pr_description_prompts.toml ✨ Enhancement +7/-0

Add repository context section to description prompt

pr_agent/settings/pr_description_prompts.toml


14. pr_agent/settings/pr_reviewer_prompts.toml ✨ Enhancement +9/-0

Add repository context section to review prompt

pr_agent/settings/pr_reviewer_prompts.toml


15. tests/unittest/test_litellm_claude_extended_thinking.py 🧪 Tests +61/-0

Add tests for Claude extended thinking model override

tests/unittest/test_litellm_claude_extended_thinking.py


16. tests/unittest/test_repo_context.py 🧪 Tests +192/-0

Add comprehensive tests for repository context functionality

tests/unittest/test_repo_context.py


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 11, 2026

Copy link
Copy Markdown
Contributor

Code Review by Qodo

🐞 Bugs (6) 📘 Rule violations (7) 📎 Requirement gaps (1) 📜 Skill insights (0)

Context used

Grey Divider


Action required

1. claude_extended_thinking_models_override undocumented 📎 Requirement gap ⚙ Maintainability ⭐ New
Description
A new operator-facing config key claude_extended_thinking_models_override was added, but the docs
section describing Claude extended-thinking parameters does not mention it. Operators may not
discover or correctly use the override behavior.
Code

pr_agent/settings/configuration.toml[R69-72]

+# Optional: override the built-in list of Claude models that receive the extended-thinking payload.
+# When non-empty, this list fully replaces the built-in defaults (see CLAUDE_EXTENDED_THINKING_MODELS
+# in pr_agent/algo/__init__.py). Leave empty to use the defaults.
+claude_extended_thinking_models_override = []
Evidence
The PR adds claude_extended_thinking_models_override to the default configuration, but the
Anthropic/Claude extended-thinking documentation section lists only
enable_claude_extended_thinking and token budget/max-output settings and does not include the new
override key or its semantics.

Override configuration key is documented for operators
pr_agent/settings/configuration.toml[69-72]
docs/docs/usage-guide/changing_a_model.md[440-447]

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 new config key `claude_extended_thinking_models_override` is not documented for operators in the docs section that describes Claude extended-thinking settings.

## Issue Context
The defaults file adds the key and explains replacement/empty semantics in comments, but operators typically rely on MkDocs pages (e.g., the model/Anthropic section) to learn available configuration.

## Fix Focus Areas
- docs/docs/usage-guide/changing_a_model.md[440-447]
- pr_agent/settings/configuration.toml[69-72]

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


2. Hardcoded secret-token test value 📘 Rule violation ⛨ Security ⭐ New
Description
A token-like secret value is committed in a unit test (user_token = "secret-token"). Even as a
placeholder, it can trip secret scanners and violates the requirement to avoid committing
secrets/tokens in tracked files.
Code

tests/unittest/test_git_provider_utils.py[133]

+            "settings": b"[github]\nuser_token = \"secret-token\"\n[pr_reviewer]\nnum_max_findings =",
Evidence
The compliance rule forbids committing access tokens/secrets in source/config/test artifacts. The
test data includes a user_token value that looks like a real token string.

AGENTS.md: No Hardcoded Secrets or Access Tokens
tests/unittest/test_git_provider_utils.py[133-133]

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 unit test embeds a token-like value (`secret-token`) in TOML content, which violates the "no hardcoded secrets/tokens" requirement.

## Issue Context
Even dummy tokens can be flagged by security tooling and should be replaced with clearly non-secret placeholders.

## Fix Focus Areas
- tests/unittest/test_git_provider_utils.py[123-146]

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


3. Long lines in repo_context.py 📘 Rule violation ⚙ Maintainability ⭐ New
Description
New code introduces lines likely exceeding the 120-character Ruff limit (e.g., the
_RepoContextCache.__init__ signature). This can cause Ruff/pre-commit failures and adds style
inconsistency.
Code

pr_agent/algo/repo_context.py[22]

+    def __init__(self, max_size: int = REPO_CONTEXT_CACHE_MAX_SIZE, ttl_seconds: int = REPO_CONTEXT_CACHE_TTL_SECONDS):
Evidence
The compliance rule requires Python changes to conform to Ruff style, including a 120-character line
limit. The _RepoContextCache.__init__ definition is written as a single long line instead of being
wrapped.

AGENTS.md: Python Code Must Conform to Ruff Style (120 Line Length, Isort Ordering, Prefer Double Quotes)
pr_agent/algo/repo_context.py[21-23]

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

## Issue description
At least one newly added line in `repo_context.py` exceeds typical Ruff line-length constraints (120), risking CI/pre-commit failures.

## Issue Context
This repository enforces Ruff style (120 max line length). Long signatures and f-strings should be wrapped across lines.

## Fix Focus Areas
- pr_agent/algo/repo_context.py[21-23]

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


View more (5)
4. Merge conflict markers committed 📘 Rule violation ≡ Correctness
Description
Unresolved Git merge conflict markers (>>>>>>) were committed into
pr_agent/git_providers/gitlab_provider.py within publish_code_suggestions(), leaving the file in
an invalid/ambiguous state. This makes the module syntactically invalid, breaking imports and
potentially crashing runtime paths and CI linting/testing.
Code

pr_agent/git_providers/gitlab_provider.py[R673-683]

+<<<<<<< feat/improvements
+                        target_file = file
+                        break
+=======
                      if file.filename == relevant_file:
                          target_file = file
                          break
              if target_file is None:
                  get_logger().warning(f"Skipping suggestion: file '{relevant_file}' not found in diff")
                  continue
+>>>>>>> main
Evidence
The PR diff shows the literal conflict marker lines (e.g., >>>>>> main) present inside the
publish_code_suggestions() function in pr_agent/git_providers/gitlab_provider.py; these markers
are not valid Python syntax, so their presence demonstrates the file cannot be parsed and will fail
linting/parsing, imports, and any runtime execution that loads the GitLab provider module.

Rule 2: No Dead or Commented-Out Code
AGENTS.md: Repository Must Remain Flake8-Clean (No Flake8 Issues Introduced): AGENTS.md: Repository Must Remain Flake8-Clean (No Flake8 Issues Introduced): AGENTS.md: Repository Must Remain Flake8-Clean (No Flake8 Issues Introduced): AGENTS.md: Repository Must Remain Flake8-Clean (No Flake8 Issues Introduced)
pr_agent/git_providers/gitlab_provider.py[673-683]
pr_agent/git_providers/gitlab_provider.py[669-684]

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

## Issue description
Resolve the committed merge conflict in `pr_agent/git_providers/gitlab_provider.py` where `publish_code_suggestions()` still contains `<<<<<<< / ======= / >>>>>>>` markers, making the module syntactically invalid.
## Issue Context
The PR diff includes conflict markers like `<<<<<<< feat/improvements`, `=======`, and `>>>>>>> main` within `publish_code_suggestions()`. This will cause a hard failure (syntax error) and must be fixed by choosing the intended logic and removing the markers so the file is valid Python and CI/runtime imports succeed.
## Fix Focus Areas
- pr_agent/git_providers/gitlab_provider.py[669-684]

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


5. Commented-out settings fetch code 📘 Rule violation ⚙ Maintainability
Description
Commented-out code was added in GithubProvider.get_repo_settings, which violates the requirement
to avoid dead/commented-out code. Leaving this in place increases maintenance burden and can confuse
future behavior expectations.
Code

pr_agent/git_providers/github_provider.py[R766-767]

+            # contents = self.repo_obj.get_contents(".pr_agent.toml", ref=self.pr.head.sha).decoded_content
+            # more logical to take 'pr_agent.toml' from the default branch
Evidence
Rule 2 forbids commented-out code in PR changes; the diff adds two commented lines in
get_repo_settings().

Rule 2: No Dead or Commented-Out Code
pr_agent/git_providers/github_provider.py[766-767]

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

## Issue description
New commented-out code was introduced in `get_repo_settings()`.
## Issue Context
The PR adds commented lines about loading `.pr_agent.toml` from `self.pr.head.sha`, but the code path now uses the default branch instead.
## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[766-767]

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


6. GitHub repo context wrong branch 🐞 Bug ≡ Correctness
Description
GithubProvider.get_repo_file_content() fetches files with no ref, which reads from the repo
default branch and can return the wrong instruction files when the PR targets a non-default base
branch. This makes the new repo_context_files feature supply incorrect context to prompts for such
PRs.
Code

pr_agent/git_providers/github_provider.py[R791-799]

+    def get_repo_file_content(self, file_path: str):
+        try:
+            contents = self.repo_obj.get_contents(file_path).decoded_content
+            if isinstance(contents, bytes):
+                return contents.decode("utf-8", errors="replace")
          return contents
-        except Exception:
+        except Exception as e:
+            get_logger().warning(f"Failed to load repo file: {file_path}, error: {e}")
          return ""
Evidence
GitHub’s implementation does not pass a base/target ref, while Gitea explicitly prefers the PR base
ref/sha for repo-context fetching, indicating the intended behavior is 'target branch when
available'.

pr_agent/git_providers/github_provider.py[791-799]
pr_agent/git_providers/gitea_provider.py[747-763]

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

## Issue description
Repo-context files for GitHub are fetched from the default branch because `get_contents(file_path)` is called without a `ref`. For PRs targeting release branches or non-default branches, instruction files can differ and the model will receive the wrong guidance.
## Issue Context
Other providers (e.g., Gitea) explicitly prefer the PR target/base ref when available.
## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[791-799]
- pr_agent/git_providers/gitea_provider.py[747-763]

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


7. Global settings leaked to PR 🐞 Bug ⛨ Security
Description
When a global org-level .pr_agent.toml fails to parse/merge, handle_configurations_errors()
publishes the full settings file content into the pull request comment thread, potentially exposing
organization-wide configuration (and any secrets mistakenly placed there) to unrelated repos’ PRs.
Code

pr_agent/git_providers/utils.py[R360-366]

+                settings_content = err['settings']
+                configuration_file_content = (
+                    settings_content.decode() if isinstance(settings_content, bytes) else settings_content
+                )
         err_message = err['error']
         config_type = err['category']
         header = f"❌ **PR-Agent failed to apply '{config_type}' repo settings**"
Evidence
The code builds a multi-file settings list that can include a global settings file, and on failure
it posts the failing content verbatim into a PR comment body.

pr_agent/git_providers/github_provider.py[737-765]
pr_agent/git_providers/utils.py[326-332]
pr_agent/git_providers/utils.py[353-373]

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

## Issue description
With org-level global settings enabled, a failure to apply repo settings can result in the raw TOML content being posted as a PR comment. This expands the blast radius: a syntax error in `<org>/pr-agent-settings/.pr_agent.toml` can cause its full contents to be echoed into PRs in other repositories.
## Issue Context
`GithubProvider.get_repo_settings()` now returns a list that may include a `(global, <bytes>)` entry. `apply_repo_settings()` forwards the failing `settings_content` into `handle_configurations_errors()`, which embeds it verbatim in a PR comment.
## Fix Focus Areas
- pr_agent/git_providers/utils.py[326-332]
- pr_agent/git_providers/utils.py[353-382]
- pr_agent/git_providers/github_provider.py[737-765]
## Suggested fix
- In `handle_configurations_errors()`, if `config_type == "global"` (or if the settings payload is marked global), do **not** include the full configuration content in the PR comment. Instead:
- Include only the error message and the fact it came from global settings, and
- Optionally include a short, bounded snippet (e.g., first 20 lines) **with redaction**, or omit entirely.
- Alternatively (or additionally), redact common secret keys (e.g., `key`, `token`, `personal_access_token`, `private_key`) before rendering any TOML content to PR comments.
- Ensure the error comment still helps operators identify *which* settings source failed without exposing its full content.

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


8. test_apply_repo_settings leaks env var 📘 Rule violation ☼ Reliability
Description
The new unit test calls apply_repo_settings(), which mutates
os.environ["AUTO_CAST_FOR_DYNACONF"], but the test does not explicitly set/reset that env var,
leaking process-global state across tests and risking order-dependent failures.
Code

tests/unittest/test_git_provider_utils.py[R46-60]

Evidence
The added test invokes apply_repo_settings() without controlling/resetting environment variables,
while apply_repo_settings() unconditionally writes to os.environ["AUTO_CAST_FOR_DYNACONF"],
creating leaked process-global state that can make tests flaky.

tests/unittest/test_git_provider_utils.py[46-60]
pr_agent/git_providers/utils.py[14-18]
Best Practice: Learned patterns

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

## Issue description
`test_apply_repo_settings_merges_global_before_local_settings()` calls `apply_repo_settings()`, which sets `os.environ["AUTO_CAST_FOR_DYNACONF"]`. The test does not explicitly manage this environment variable, so the process-global state can leak into other tests.
## Issue Context
`apply_repo_settings()` mutates `AUTO_CAST_FOR_DYNACONF` unconditionally. Per the test hygiene rule, tests must explicitly set/delete env vars they affect and ensure cleanup to avoid flaky, order-dependent outcomes.
## Fix Focus Areas
- tests/unittest/test_git_provider_utils.py[46-60]

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



Remediation recommended

9. Hardcoded repo-context cache TTL 📘 Rule violation ⚙ Maintainability ⭐ New
Description
Repo-context caching limits (REPO_CONTEXT_CACHE_MAX_SIZE and REPO_CONTEXT_CACHE_TTL_SECONDS) are
hardcoded in Python rather than being configurable via .pr_agent.toml / pr_agent/settings/. This
makes runtime behavior harder to tune without code changes.
Code

pr_agent/algo/repo_context.py[R14-16]

+REPO_CONTEXT_CACHE_ATTRIBUTE = "_repo_context_cache"
+REPO_CONTEXT_CACHE_MAX_SIZE = 256
+REPO_CONTEXT_CACHE_TTL_SECONDS = 15 * 60
Evidence
The compliance rule requires runtime behavior changes to be configurable via the supported config
system rather than hardcoded values in code. The new caching behavior introduces fixed TTL/size
constants in repo_context.py.

AGENTS.md: Configuration Must Be Changed via .pr_agent.toml or pr_agent/settings/ (No Hardcoded Runtime Values)
pr_agent/algo/repo_context.py[14-16]

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

## Issue description
Repo-context cache size and TTL are hardcoded constants, which bypasses the supported configuration mechanism.

## Issue Context
Operators may need to tune cache TTL/size for different deployment sizes and workloads; these should be configurable through Dynaconf (.pr_agent.toml / pr_agent/settings/configuration.toml).

## Fix Focus Areas
- pr_agent/algo/repo_context.py[14-16]
- pr_agent/settings/configuration.toml[28-32]

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


10. Repo settings error misattributed 🐞 Bug ≡ Correctness ⭐ New
Description
apply_repo_settings() reports repo settings failures using the last normalized settings entry, which
mislabels global-org settings parsing failures as "local" when both global and local settings are
merged. This leads to incorrect user-facing error handling in handle_configurations_errors() (e.g.,
showing local config content while the actual failure is in the global settings file).
Code

pr_agent/git_providers/utils.py[R327-330]

+                    category = normalized_repo_settings[-1][0] if normalized_repo_settings else "local"
+                    settings_content = normalized_repo_settings[-1][1] if normalized_repo_settings else repo_settings
                    get_logger().warning(f"Failed to apply repo {category} settings, error: {str(e)}")
-                    error_local = {'error': str(e), 'settings': repo_settings, 'category': category}
+                    error_local = {'error': str(e), 'settings': settings_content, 'category': category}
Evidence
The PR changed repo settings to support multiple settings files (global + local). On exception,
apply_repo_settings selects the last entry’s category/content, but GithubProvider returns global
first then local. This makes global failures reported as local, which alters the global-safe branch
in handle_configurations_errors().

pr_agent/git_providers/utils.py[258-333]
pr_agent/git_providers/utils.py[354-381]
pr_agent/git_providers/github_provider.py[738-774]

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

### Issue description
`apply_repo_settings()` now supports multiple settings sources (e.g., `[("global", ...), ("local", ...)]`), but on any exception it always sets `category`/`settings_content` from `normalized_repo_settings[-1]`. This misattributes failures (often blaming `local` even when `global` is the broken file), which also changes downstream behavior in `handle_configurations_errors()`.

### Issue Context
- `GithubProvider.get_repo_settings()` can return a list of `(category, bytes)` where `global` is first and `local` is second.
- `handle_configurations_errors()` special-cases `category == "global"` to avoid rendering config content.
- Mislabeling a global parse error as local both misleads users and can trigger the wrong content-rendering branch.

### Fix Focus Areas
- pr_agent/git_providers/utils.py[274-333]
- pr_agent/git_providers/utils.py[354-381]
- pr_agent/git_providers/github_provider.py[738-774]

### Suggested fix approach
1. When catching the exception, determine *which* settings file failed:
  - Option A (best): attempt to parse each settings file independently (in order) using Dynaconf (or a TOML parser) to identify the first invalid file, then set `category/settings_content` from that specific entry.
  - Option B (fallback): if any `(category == "global")` exists and parsing failed, report category as `global` to ensure the global-safe error handling path is taken.
2. Keep the existing merge behavior for valid files.

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


11. _get_repo_context_process_cache_key bare except 📘 Rule violation ⚙ Maintainability
Description
_get_repo_context_process_cache_key() uses a bare except Exception: without capturing/logging
the exception, which can silently hide real provider failures and make debugging repo-context
behavior difficult.
Code

pr_agent/algo/repo_context.py[R66-71]

+def _get_repo_context_process_cache_key(git_provider, context_files: list, max_lines: int) -> tuple | None:
+    try:
+        pr_url = git_provider.get_pr_url()
+    except Exception:
+        pr_url = getattr(git_provider, "pr_url", None)
+
Evidence
PR Compliance ID 19 requires narrow exception handling and capturing exception objects for logging.
The newly added code catches broadly and does not bind/log the exception before falling back to
git_provider.pr_url.

pr_agent/algo/repo_context.py[66-71]
Best Practice: Learned patterns

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

## Issue description
`_get_repo_context_process_cache_key()` uses `except Exception:` without binding the exception (e.g., `as e`) and without logging it. This can mask unexpected provider issues and reduces debuggability.
## Issue Context
This code determines whether process-level caching is used. If `get_pr_url()` fails for reasons other than a missing method/attribute, the failure is silently swallowed.
## Fix Focus Areas
- pr_agent/algo/repo_context.py[66-71]

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


View more (2)
12. Stale Gitea repo context 🐞 Bug ≡ Correctness
Description
GiteaProvider.get_repo_file_content() prefers the PR base commit SHA over the base branch ref, so
repo_context_files can be loaded from an outdated snapshot when the target branch advances after PR
creation. This can cause PR-Agent to include stale instruction files in prompts.
Code

pr_agent/git_providers/gitea_provider.py[R747-770]

+    def get_repo_file_content(self, file_path: str) -> str:
+        """Get content of a file from the repository target branch.
+
+        This method implements the interface required by PR #2387 repo_context feature.
+        It retrieves file content from the PR target when available, falling back to
+        the PR head commit for non-PR contexts.
+        """
+        try:
+            if not self.owner or not self.repo:
+                self.logger.warning("Cannot get repo file content: owner or repo not set")
+                return ""
+
+            ref = self.base_sha or self.base_ref or self.sha
+            if not ref:
+                self.logger.warning("Cannot get repo file content: ref not set")
+                return ""
+
+            content = self.repo_api.get_file_content(
+                owner=self.owner,
+                repo=self.repo,
+                commit_sha=ref,
+                filepath=file_path
+            )
+            return content
Evidence
The provider stores both base_sha (base commit) and base_ref (target branch name), but the new
fetch logic uses base_sha first, so it can return content from an older commit even when the base
branch has moved forward.

pr_agent/git_providers/gitea_provider.py[88-99]
pr_agent/git_providers/gitea_provider.py[747-770]
pr_agent/git_providers/gitea_provider.py[951-959]

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

## Issue description
`GiteaProvider.get_repo_file_content()` selects `base_sha` before `base_ref`, which pins instruction-file reads to the PR base commit rather than the current target branch tip.
## Issue Context
The repo-context feature is meant to load project instruction files (e.g., `AGENTS.md`) from the repository’s target branch context.
## Fix Focus Areas
- pr_agent/git_providers/gitea_provider.py[747-773]
- pr_agent/git_providers/gitea_provider.py[88-99]

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


13. GitLab context wrong branch 🐞 Bug ≡ Correctness
Description
GitLabProvider.get_repo_file_content() always reads from the project default branch, which can
differ from the merge request target branch. This can cause repo_context_files to be taken from the
wrong branch for MRs targeting release/hotfix branches.
Code

pr_agent/git_providers/gitlab_provider.py[R802-811]

+    def get_repo_file_content(self, file_path: str):
+        try:
+            project = self.gl.projects.get(self.id_project)
+            contents = project.files.get(file_path=file_path, ref=project.default_branch).decode()
+            return decode_if_bytes(contents)
+        except GitlabGetError:
+            return ""
+        except Exception as e:
+            get_logger().warning(f"Failed to load repo file: {file_path}, error: {e}")
+            return ""
Evidence
The new GitLab repo file fetch hard-codes project.default_branch, while the provider already has
access to mr.target_branch (used elsewhere), so it can and should use the MR target branch when
present.

pr_agent/git_providers/gitlab_provider.py[802-812]
pr_agent/git_providers/gitlab_provider.py[81-124]

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

## Issue description
`GitLabProvider.get_repo_file_content()` fetches files from `project.default_branch` unconditionally, ignoring `mr.target_branch`.
## Issue Context
Repo context files should reflect the PR/MR target branch when available to avoid pulling instruction files from a different branch.
## Fix Focus Areas
- pr_agent/git_providers/gitlab_provider.py[802-812]
- pr_agent/git_providers/gitlab_provider.py[81-124]

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



Informational

14. FakeRepo stub ignores ref kwarg 🐞 Bug ☼ Reliability ⭐ New
Description
tests/unittest/test_github_provider_settings.py defines FakeRepo.get_contents(path) without
accepting a ref= kwarg, but GithubProvider.get_repo_settings() will call get_contents(path, ref=...)
whenever PR_AGENT_CONFIG_BRANCH or CONFIG.CONFIG_BRANCH is set. If that env var is present during
test execution, these tests will fail with a TypeError.
Code

tests/unittest/test_github_provider_settings.py[R10-18]

+class FakeRepo:
+    def __init__(self, files=None):
+        self.files = files or {}
+
+    def get_contents(self, path):
+        if path not in self.files:
+            raise FileNotFoundError(path)
+        return FakeContent(self.files[path])
+
Evidence
GithubProvider.get_repo_settings reads PR_AGENT_CONFIG_BRANCH and calls repo_obj.get_contents with
ref=..., while the FakeRepo stub only accepts a positional path parameter.

pr_agent/git_providers/github_provider.py[744-760]
tests/unittest/test_github_provider_settings.py[10-18]

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

### Issue description
`FakeRepo.get_contents()` in `test_github_provider_settings.py` does not accept `ref=...`, but production `GithubProvider.get_repo_settings()` may pass `ref` when config-branch is configured.

### Issue Context
This becomes a deterministic failure when `PR_AGENT_CONFIG_BRANCH` is set in the environment (or when tests set CONFIG.CONFIG_BRANCH), causing `TypeError: get_contents() got an unexpected keyword argument 'ref'`.

### Fix Focus Areas
- tests/unittest/test_github_provider_settings.py[10-18]
- pr_agent/git_providers/github_provider.py[746-756]

### Suggested fix approach
- Update `FakeRepo.get_contents` signature to accept `ref=None, **kwargs` (and ignore it), or
- Explicitly clear `PR_AGENT_CONFIG_BRANCH` / CONFIG.CONFIG_BRANCH in these tests.

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


Grey Divider

  • Author self-review: I have reviewed the code review findings, and addressed the relevant ones.

Previous review results

Review updated until commit c7d0812

Results up to commit 48338a2


🐞 Bugs (4) 📘 Rule violations (4) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

Action required
1. Merge conflict markers committed 📘 Rule violation ≡ Correctness
Description
Unresolved Git merge conflict markers (>>>>>>) were committed into
pr_agent/git_providers/gitlab_provider.py within publish_code_suggestions(), leaving the file in
an invalid/ambiguous state. This makes the module syntactically invalid, breaking imports and
potentially crashing runtime paths and CI linting/testing.
Code

pr_agent/git_providers/gitlab_provider.py[R673-683]

+<<<<<<< feat/improvements
+                        target_file = file
+                        break
+=======
                       if file.filename == relevant_file:
                           target_file = file
                           break
               if target_file is None:
                   get_logger().warning(f"Skipping suggestion: file '{relevant_file}' not found in diff")
                   continue
+>>>>>>> main
Evidence
The PR diff shows the literal conflict marker lines (e.g., >>>>>> main) present inside the
publish_code_suggestions() function in pr_agent/git_providers/gitlab_provider.py; these markers
are not valid Python syntax, so their presence demonstrates the file cannot be parsed and will fail
linting/parsing, imports, and any runtime execution that loads the GitLab provider module.

Rule 2: No Dead or Commented-Out Code
AGENTS.md: Repository Must Remain Flake8-Clean (No Flake8 Issues Introduced): AGENTS.md: Repository Must Remain Flake8-Clean (No Flake8 Issues Introduced)
pr_agent/git_providers/gitlab_provider.py[673-683]
pr_agent/git_providers/gitlab_provider.py[669-684]

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

## Issue description
Resolve the committed merge conflict in `pr_agent/git_providers/gitlab_provider.py` where `publish_code_suggestions()` still contains `<<<<<<< / ======= / >>>>>>>` markers, making the module syntactically invalid.
## Issue Context
The PR diff includes conflict markers like `<<<<<<< feat/improvements`, `=======`, and `>>>>>>> main` within `publish_code_suggestions()`. This will cause a hard failure (syntax error) and must be fixed by choosing the intended logic and removing the markers so the file is valid Python and CI/runtime imports succeed.
## Fix Focus Areas
- pr_agent/git_providers/gitlab_provider.py[669-684]

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


2. Commented-out settings fetch code 📘 Rule violation ⚙ Maintainability
Description
Commented-out code was added in GithubProvider.get_repo_settings, which violates the requirement
to avoid dead/commented-out code. Leaving this in place increases maintenance burden and can confuse
future behavior expectations.
Code

pr_agent/git_providers/github_provider.py[R766-767]

+            # contents = self.repo_obj.get_contents(".pr_agent.toml", ref=self.pr.head.sha).decoded_content
+            # more logical to take 'pr_agent.toml' from the default branch
Evidence
Rule 2 forbids commented-out code in PR changes; the diff adds two commented lines in
get_repo_settings().

Rule 2: No Dead or Commented-Out Code
pr_agent/git_providers/github_provider.py[766-767]

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

## Issue description
New commented-out code was introduced in `get_repo_settings()`.
## Issue Context
The PR adds commented lines about loading `.pr_agent.toml` from `self.pr.head.sha`, but the code path now uses the default branch instead.
## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[766-767]

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


3. GitHub repo context wrong branch 🐞 Bug ≡ Correctness
Description
GithubProvider.get_repo_file_content() fetches files with no ref, which reads from the repo
default branch and can return the wrong instruction files when the PR targets a non-default base
branch. This makes the new repo_context_files feature supply incorrect context to prompts for such
PRs.
Code

pr_agent/git_providers/github_provider.py[R791-799]

+    def get_repo_file_content(self, file_path: str):
+        try:
+            contents = self.repo_obj.get_contents(file_path).decoded_content
+            if isinstance(contents, bytes):
+                return contents.decode("utf-8", errors="replace")
           return contents
-        except Exception:
+        except Exception as e:
+            get_logger().warning(f"Failed to load repo file: {file_path}, error: {e}")
           return ""
Evidence
GitHub’s implementation does not pass a base/target ref, while Gitea explicitly prefers the PR base
ref/sha for repo-context fetching, indicating the intended behavior is 'target branch when
available'.

pr_agent/git_providers/github_provider.py[791-799]
pr_agent/git_providers/gitea_provider.py[747-763]

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

## Issue description
Repo-context files for GitHub are fetched from the default branch because `get_contents(file_path)` is called without a `ref`. For PRs targeting release branches or non-default branches, instruction files can differ and the model will receive the wrong guidance.
## Issue Context
Other providers (e.g., Gitea) explicitly prefer the PR target/base ref when available.
## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[791-799]
- pr_agent/git_providers/gitea_provider.py[747-763]

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


View more (2)
4. Global settings leaked to PR 🐞 Bug ⛨ Security
Description
When a global org-level .pr_agent.toml fails to parse/merge, handle_configurations_errors()
publishes the full settings file content into the pull request comment thread, potentially exposing
organization-wide configuration (and any secrets mistakenly placed there) to unrelated repos’ PRs.
Code

pr_agent/git_providers/utils.py[R360-366]

+                settings_content = err['settings']
+                configuration_file_content = (
+                    settings_content.decode() if isinstance(settings_content, bytes) else settings_content
+                )
          err_message = err['error']
          config_type = err['category']
          header = f"❌ **PR-Agent failed to apply '{config_type}' repo settings**"
Evidence
The code builds a multi-file settings list that can include a global settings file, and on failure
it posts the failing content verbatim into a PR comment body.

pr_agent/git_providers/github_provider.py[737-765]
pr_agent/git_providers/utils.py[326-332]
pr_agent/git_providers/utils.py[353-373]

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

## Issue description
With org-level global settings enabled, a failure to apply repo settings can result in the raw TOML content being posted as a PR comment. This expands the blast radius: a syntax error in `<org>/pr-agent-settings/.pr_agent.toml` can cause its full contents to be echoed into PRs in other repositories.
## Issue Context
`GithubProvider.get_repo_settings()` now returns a list that may include a `(global, <bytes>)` entry. `apply_repo_settings()` forwards the failing `settings_content` into `handle_configurations_errors()`, which embeds it verbatim in a PR comment.
## Fix Focus Areas
- pr_agent/git_providers/utils.py[326-332]
- pr_agent/git_providers/utils.py[353-382]
- pr_agent/git_providers/github_provider.py[737-765]
## Suggested fix
- In `handle_configurations_errors()`, if `config_type == "global"` (or if the settings payload is marked global), do **not** include the full configuration content in the PR comment. Instead:
- Include only the error message and the fact it came from global settings, and
- Optionally include a short, bounded snippet (e.g., first 20 lines) **with redaction**, or omit entirely.
- Alternatively (or additionally), redact common secret keys (e.g., `key`, `token`, `personal_access_token`, `private_key`) before rendering any TOML content to PR comments.
- Ensure the error comment still helps operators identify *which* settings source failed without exposing its full content.

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


5. test_apply_repo_settings leaks env var 📘 Rule violation ☼ Reliability
Description
The new unit test calls apply_repo_settings(), which mutates
os.environ["AUTO_CAST_FOR_DYNACONF"], but the test does not explicitly set/reset that env var,
leaking process-global state across tests and risking order-dependent failures.
Code

tests/unittest/test_git_provider_utils.py[R46-60]

Evidence
The added test invokes apply_repo_settings() without controlling/resetting environment variables,
while apply_repo_settings() unconditionally writes to os.environ["AUTO_CAST_FOR_DYNACONF"],
creating leaked process-global state that can make tests flaky.

tests/unittest/test_git_provider_utils.py[46-60]
pr_agent/git_providers/utils.py[14-18]
Best Practice: Learned patterns

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

## Issue description
`test_apply_repo_settings_merges_global_before_local_settings()` calls `apply_repo_settings()`, which sets `os.environ["AUTO_CAST_FOR_DYNACONF"]`. The test does not explicitly manage this environment variable, so the process-global state can leak into other tests.
## Issue Context
`apply_repo_settings()` mutates `AUTO_CAST_FOR_DYNACONF` unconditionally. Per the test hygiene rule, tests must explicitly set/delete env vars they affect and ensure cleanup to avoid flaky, order-dependent outcomes.
## Fix Focus Areas
- tests/unittest/test_git_provider_utils.py[46-60]

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



Remediation recommended
6. _get_repo_context_process_cache_key bare except 📘 Rule violation ⚙ Maintainability ⭐ New
Description
_get_repo_context_process_cache_key() uses a bare except Exception: without capturing/logging
the exception, which can silently hide real provider failures and make debugging repo-context
behavior difficult.
Code

pr_agent/algo/repo_context.py[R66-71]

+def _get_repo_context_process_cache_key(git_provider, context_files: list, max_lines: int) -> tuple | None:
+    try:
+        pr_url = git_provider.get_pr_url()
+    except Exception:
+        pr_url = getattr(git_provider, "pr_url", None)
+
Evidence
PR Compliance ID 19 requires narrow exception handling and capturing exception objects for logging.
The newly added code catches broadly and does not bind/log the exception before falling back to
git_provider.pr_url.

pr_agent/algo/repo_context.py[66-71]
Best Practice: Learned patterns

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

## Issue description
`_get_repo_context_process_cache_key()` uses `except Exception:` without binding the exception (e.g., `as e`) and without logging it. This can mask unexpected provider issues and reduces debuggability.

## Issue Context
This code determines whether process-level caching is used. If `get_pr_url()` fails for reasons other than a missing method/attribute, the failure is silently swallowed.

## Fix Focus Areas
- pr_agent/algo/repo_context.py[66-71]

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


7. Stale Gitea repo context 🐞 Bug ≡ Correctness ⭐ New
Description
GiteaProvider.get_repo_file_content() prefers the PR base commit SHA over the base branch ref, so
repo_context_files can be loaded from an outdated snapshot when the target branch advances after PR
creation. This can cause PR-Agent to include stale instruction files in prompts.
Code

pr_agent/git_providers/gitea_provider.py[R747-770]

+    def get_repo_file_content(self, file_path: str) -> str:
+        """Get content of a file from the repository target branch.
+
+        This method implements the interface required by PR #2387 repo_context feature.
+        It retrieves file content from the PR target when available, falling back to
+        the PR head commit for non-PR contexts.
+        """
+        try:
+            if not self.owner or not self.repo:
+                self.logger.warning("Cannot get repo file content: owner or repo not set")
+                return ""
+
+            ref = self.base_sha or self.base_ref or self.sha
+            if not ref:
+                self.logger.warning("Cannot get repo file content: ref not set")
+                return ""
+
+            content = self.repo_api.get_file_content(
+                owner=self.owner,
+                repo=self.repo,
+                commit_sha=ref,
+                filepath=file_path
+            )
+            return content
Evidence
The provider stores both base_sha (base commit) and base_ref (target branch name), but the new
fetch logic uses base_sha first, so it can return content from an older commit even when the base
branch has moved forward.

pr_agent/git_providers/gitea_provider.py[88-99]
pr_agent/git_providers/gitea_provider.py[747-770]
pr_agent/git_providers/gitea_provider.py[951-959]

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

## Issue description
`GiteaProvider.get_repo_file_content()` selects `base_sha` before `base_ref`, which pins instruction-file reads to the PR base commit rather than the current target branch tip.

## Issue Context
The repo-context feature is meant to load project instruction files (e.g., `AGENTS.md`) from the repository’s target branch context.

## Fix Focus Areas
- pr_agent/git_providers/gitea_provider.py[747-773]
- pr_agent/git_providers/gitea_provider.py[88-99]

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


8. GitLab context wrong branch 🐞 Bug ≡ Correctness ⭐ New
Description
GitLabProvider.get_repo_file_content() always reads from the project default branch, which can
differ from the merge request target branch. This can cause repo_context_files to be taken from the
wrong branch for MRs targeting release/hotfix branches.
Code

pr_agent/git_providers/gitlab_provider.py[R802-811]

+    def get_repo_file_content(self, file_path: str):
+        try:
+            project = self.gl.projects.get(self.id_project)
+            contents = project.files.get(file_path=file_path, ref=project.default_branch).decode()
+            return decode_if_bytes(contents)
+        except GitlabGetError:
+            return ""
+        except Exception as e:
+            get_logger().warning(f"Failed to load repo file: {file_path}, error: {e}")
+            return ""
Evidence
The new GitLab repo file fetch hard-codes project.default_branch, while the provider already has
access to mr.target_branch (used elsewhere), so it can and should use the MR target branch when
present.

pr_agent/git_providers/gitlab_provider.py[802-812]
[pr_agent/git_providers/gitlab_provider.py[81-124]](...

Comment thread pr_agent/algo/repo_context.py Outdated
Comment thread pr_agent/algo/repo_context.py Outdated
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 11, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 2b313ad

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 11, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 50de2c6

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 11, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit e93cad2

Comment thread pr_agent/algo/repo_context.py Outdated
@geanpereira96

Copy link
Copy Markdown

Hey, could you adjust your implementation for Gitea in gitea_provider.py?

I made it manually for now, but I think it would be interesting to include it in this PR as well.
gitea_provider.py

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 14, 2026

Copy link
Copy Markdown
Contributor

Code Review by Qodo

Grey Divider

New Review Started

This review has been superseded by a new analysis

Grey Divider

Qodo Logo

@avidspartan1

Copy link
Copy Markdown
Author

Hey, could you adjust your implementation for Gitea in gitea_provider.py?

I made it manually for now, but I think it would be interesting to include it in this PR as well. gitea_provider.py

done!

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 14, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 2e11c1f

Comment thread tests/unittest/test_repo_context.py
Comment thread pr_agent/git_providers/gitea_provider.py
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 14, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 145b93f

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 14, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit a92f7b3

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 15, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 982821f

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 817fa77

Comment thread pr_agent/algo/repo_context.py
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

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

Comment thread pr_agent/git_providers/gitea_provider.py
Comment thread tests/unittest/test_repo_context.py Outdated
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 5dde4dc

Comment thread tests/unittest/test_git_provider_utils.py
@avidspartan1

Copy link
Copy Markdown
Author

/describe

@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

PR Description updated to latest commit (5dde4dc)

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 92189c3

Comment thread pr_agent/git_providers/utils.py
@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

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

@naorpeled

Copy link
Copy Markdown
Member

Hey @avidspartan1,
Thanks for this great work!

Can you please rebase onto main and resolve the leftover Qodo comments? 🙏

@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Looking for bugs?

Check back in a few minutes. Qodo's review agents are on it.

@avidspartan1

avidspartan1 commented Jun 22, 2026

Copy link
Copy Markdown
Author

Hey @avidspartan1, Thanks for this great work!

Can you please rebase onto main and resolve the leftover Qodo comments? 🙏

Thanks, @naorpeled! I've prioritized the "Action required" comments from the review, but left the "Review recommended". I think I've pushed quite a few times, so PR Agent has been generating a lot of comments. 😆 If you'd like me to resolve all of them I can give that a shot; I'm just afraid of introducing too many changes / scope creep from my original goals. Let me know!

Comment on lines +673 to +683
<<<<<<< feat/improvements
target_file = file
break
=======
if file.filename == relevant_file:
target_file = file
break
if target_file is None:
get_logger().warning(f"Skipping suggestion: file '{relevant_file}' not found in diff")
continue
>>>>>>> main

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

1. Merge conflict markers committed 📘 Rule violation ≡ Correctness

Unresolved Git merge conflict markers (<<<<<<<, =======, >>>>>>>) were committed into
pr_agent/git_providers/gitlab_provider.py within publish_code_suggestions(), leaving the file in
an invalid/ambiguous state. This makes the module syntactically invalid, breaking imports and
potentially crashing runtime paths and CI linting/testing.
Agent Prompt
## Issue description
Resolve the committed merge conflict in `pr_agent/git_providers/gitlab_provider.py` where `publish_code_suggestions()` still contains `<<<<<<< / ======= / >>>>>>>` markers, making the module syntactically invalid.

## Issue Context
The PR diff includes conflict markers like `<<<<<<< feat/improvements`, `=======`, and `>>>>>>> main` within `publish_code_suggestions()`. This will cause a hard failure (syntax error) and must be fixed by choosing the intended logic and removing the markers so the file is valid Python and CI/runtime imports succeed.

## Fix Focus Areas
- pr_agent/git_providers/gitlab_provider.py[669-684]

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

Comment on lines +766 to +767
# contents = self.repo_obj.get_contents(".pr_agent.toml", ref=self.pr.head.sha).decoded_content
# more logical to take 'pr_agent.toml' from the default branch

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

2. Commented-out settings fetch code 📘 Rule violation ⚙ Maintainability

Commented-out code was added in GithubProvider.get_repo_settings, which violates the requirement
to avoid dead/commented-out code. Leaving this in place increases maintenance burden and can confuse
future behavior expectations.
Agent Prompt
## Issue description
New commented-out code was introduced in `get_repo_settings()`.

## Issue Context
The PR adds commented lines about loading `.pr_agent.toml` from `self.pr.head.sha`, but the code path now uses the default branch instead.

## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[766-767]

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

Comment on lines +791 to 799
def get_repo_file_content(self, file_path: str):
try:
contents = self.repo_obj.get_contents(file_path).decoded_content
if isinstance(contents, bytes):
return contents.decode("utf-8", errors="replace")
return contents
except Exception:
except Exception as e:
get_logger().warning(f"Failed to load repo file: {file_path}, error: {e}")
return ""

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

4. Github repo context wrong branch 🐞 Bug ≡ Correctness

GithubProvider.get_repo_file_content() fetches files with no ref, which reads from the repo
default branch and can return the wrong instruction files when the PR targets a non-default base
branch. This makes the new repo_context_files feature supply incorrect context to prompts for such
PRs.
Agent Prompt
## Issue description
Repo-context files for GitHub are fetched from the default branch because `get_contents(file_path)` is called without a `ref`. For PRs targeting release branches or non-default branches, instruction files can differ and the model will receive the wrong guidance.

## Issue Context
Other providers (e.g., Gitea) explicitly prefer the PR target/base ref when available.

## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[791-799]
- pr_agent/git_providers/gitea_provider.py[747-763]

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

@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 70895f1

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Code Review by Qodo

Grey Divider

New Review Started

This review has been superseded by a new analysis

Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 48338a2

Comment on lines +69 to +72
# Optional: override the built-in list of Claude models that receive the extended-thinking payload.
# When non-empty, this list fully replaces the built-in defaults (see CLAUDE_EXTENDED_THINKING_MODELS
# in pr_agent/algo/__init__.py). Leave empty to use the defaults.
claude_extended_thinking_models_override = []

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

1. claude_extended_thinking_models_override undocumented 📎 Requirement gap ⚙ Maintainability

A new operator-facing config key claude_extended_thinking_models_override was added, but the docs
section describing Claude extended-thinking parameters does not mention it. Operators may not
discover or correctly use the override behavior.
Agent Prompt
## Issue description
The new config key `claude_extended_thinking_models_override` is not documented for operators in the docs section that describes Claude extended-thinking settings.

## Issue Context
The defaults file adds the key and explains replacement/empty semantics in comments, but operators typically rely on MkDocs pages (e.g., the model/Anthropic section) to learn available configuration.

## Fix Focus Areas
- docs/docs/usage-guide/changing_a_model.md[440-447]
- pr_agent/settings/configuration.toml[69-72]

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

},
{
"settings": b"[pr_reviewer]\nnum_max_findings =",
"settings": b"[github]\nuser_token = \"secret-token\"\n[pr_reviewer]\nnum_max_findings =",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

2. Hardcoded secret-token test value 📘 Rule violation ⛨ Security

A token-like secret value is committed in a unit test (user_token = "secret-token"). Even as a
placeholder, it can trip secret scanners and violates the requirement to avoid committing
secrets/tokens in tracked files.
Agent Prompt
## Issue description
The unit test embeds a token-like value (`secret-token`) in TOML content, which violates the "no hardcoded secrets/tokens" requirement.

## Issue Context
Even dummy tokens can be flagged by security tooling and should be replaced with clearly non-secret placeholders.

## Fix Focus Areas
- tests/unittest/test_git_provider_utils.py[123-146]

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



class _RepoContextCache:
def __init__(self, max_size: int = REPO_CONTEXT_CACHE_MAX_SIZE, ttl_seconds: int = REPO_CONTEXT_CACHE_TTL_SECONDS):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

4. Long lines in repo_context.py 📘 Rule violation ⚙ Maintainability

New code introduces lines likely exceeding the 120-character Ruff limit (e.g., the
_RepoContextCache.__init__ signature). This can cause Ruff/pre-commit failures and adds style
inconsistency.
Agent Prompt
## Issue description
At least one newly added line in `repo_context.py` exceeds typical Ruff line-length constraints (120), risking CI/pre-commit failures.

## Issue Context
This repository enforces Ruff style (120 max line length). Long signatures and f-strings should be wrapped across lines.

## Fix Focus Areas
- pr_agent/algo/repo_context.py[21-23]

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

@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support Claude Sonnet extended thinking models

4 participants