fix(github): create missing changelog file when pushing updates - #3639

• Create files when GitHub returns 404 instead of attempting an invalid SHA-less update.
• Preserve SHA-based updates for existing files and propagate unrelated read failures.
• Add regression coverage for missing files and non-404 errors.

graph TD
  A["Write file request"] --> B["Read branch file"] --> C{"Read result"}
  C -->|Found| D["Update with SHA"] --> G["Return commit"]
  C -->|404| E["Create file"] --> G
  C -->|Other error| F["Propagate error"]

Loading

The status-directed create-or-update flow is the appropriate approach because GitHub exposes separate APIs rather than an atomic upsert. It preserves required SHA-based updates while restricting creation to a confirmed 404; optimistic update retries or broad exception handling could mask authorization, transport, or service failures.

Bug fix (1) +19 / -11

github_provider.pyCreate absent files and preserve GitHub read failures +19/-11

Create absent files and preserve GitHub read failures

• The provider now creates a file when its branch lookup returns 404 and updates existing files using their blob SHA. Non-404 GitHub errors are reraised without attempting either write operation.

pr_agent/git_providers/github_provider.py

Tests (1) +45 / -0

test_github_provider_file_content.pyCover missing-file creation and failed-read handling +45/-0

Cover missing-file creation and failed-read handling

• Adds regression tests verifying that 404 responses call 'create_file' and return its commit. Also verifies that non-404 lookup errors propagate without creating or updating a file.

tests/unittest/test_github_provider_file_content.py

Description

create_or_update_pr_file calls create_file on _get_repo(), which resolves the base repository
from the pull request URL, while its branch argument comes from the unqualified pr.head.ref.
When a fork’s source branch name also exists in the base repository and lacks the requested file,
the new 404 path creates the changelog on that unrelated base branch; if the name does not exist
there, the intended fork update fails.

Code

pr_agent/git_providers/github_provider.py[R1702-1705]

+            response = repo.create_file(
+                path=file_path,
+                message=message,
+                content=contents,

Evidence

set_pr derives self.repo from the pull request URL, and _get_repo resolves that repository,
while get_pr_branch independently returns the head ref without its repository identity. The
changed create path then applies that head branch name to the base repository object, and the
changelog caller supplies exactly this branch value.

pr_agent/git_providers/github_provider.py[213-215]
pr_agent/git_providers/github_provider.py[1221-1222]
pr_agent/git_providers/github_provider.py[1657-1664]
pr_agent/git_providers/github_provider.py[1696-1715]
pr_agent/tools/pr_update_changelog.py[287-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
Fork pull request writes combine the base repository selected by `_get_repo()` with the source branch name returned by `get_pr_branch()`. The new missing-file path can therefore create `CHANGELOG.md` on a same-named base branch rather than the fork branch.
## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[1696-1715]
- pr_agent/git_providers/github_provider.py[1221-1222]
- tests/unittest/test_github_provider_file_content.py[77-119]
## Recommended Fix
Resolve the write repository and branch as one matched pull-request-head target, using the head repository together with `pr.head.ref` for the existence check, creation, and update. Add a fork regression test with a same-named base branch and assert that the base repository is never read or written while the head repository receives the create call; propagate an access failure when the head repository cannot be written.

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

Description

The _pr_head_in_base_repo docstring begins with True when, while the new fork-handling comments
describe behavior narratively instead of using imperative phrasing. These additions establish the
same nonconforming style across production logic and regression tests, encouraging later
explanations of this branch behavior to follow it.

Code

pr_agent/git_providers/github_provider.py[1725]

+        """True when the pull request head branch lives in the base repository itself.

Evidence

Compliance rule 2694688 requires added docstrings and behavioral comments to use imperative
phrasing. The cited additions instead begin with True when, A fork pull request resolves, `Fork
pull request, and GitHub reports`, all of which are descriptive rather than imperative.

Rule 2694688: Docstrings and comments must use imperative phrasing
pr_agent/git_providers/github_provider.py[1703-1706]
pr_agent/git_providers/github_provider.py[1725-1730]
tests/unittest/test_github_provider_file_content.py[112-113]
tests/unittest/test_github_provider_file_content.py[138-138]

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 `_pr_head_in_base_repo` docstring and fork-handling comments use descriptive or fragmentary phrasing rather than the required imperative style.
## Fix Focus Areas
- pr_agent/git_providers/github_provider.py[1703-1706]
- pr_agent/git_providers/github_provider.py[1725-1730]
- tests/unittest/test_github_provider_file_content.py[112-113]
- tests/unittest/test_github_provider_file_content.py[138-138]
## Recommended Fix
Rewrite the docstring to begin with an imperative phrase such as `Return whether`, and rewrite the behavioral comments as concise instructions while preserving their meaning.

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

💡 Did you know, you can choose which labels appear on a finding, and whether they show icons or text

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗