Skip to content

feat(status): acknowledge a pull request the moment automatic commands start - #3091

Open
dwin-gharibi wants to merge 4 commits into
The-PR-Agent:mainfrom
dwin-gharibi:feat/immediate-pr-acknowledgment
Open

dwin-gharibi wants to merge 4 commits into
The-PR-Agent:mainfrom
dwin-gharibi:feat/immediate-pr-acknowledgment

Conversation

@dwin-gharibi

Copy link
Copy Markdown
Contributor

Implements #3090.

Description

An automatic command sets config.is_auto_command, which suppresses the "Preparing review…"
progress comment. Between opening a pull request and the model answering — often a minute or more
on a large diff — nothing tells the author that PR-Agent is running, or whether the webhook arrived
at all.

What changed

A provider primitive. GitProvider.publish_run_status(state, description) where state is
pending, success or failure. The base implementation returns False, so providers without a
commit-status API are a no-op.

  • GitHub — a commit status on the PR head (create_status), truncating the description to the
    140 characters GitHub accepts.
  • GitLab — a commit status too, mapping failure to GitLab's spelling, failed.

A commit status was chosen over a comment because it is not part of the conversation: it appears
in the PR's checks area immediately and is replaced in place, so re-running adds no noise. It also
needs no extra permission beyond what PR-Agent already has, unlike the Checks API.

Wiring. _perform_auto_commands_github publishes pending before the command loop and
success / failure after it, tracking both a command that returns False and one that raises.

Configuration, off by default:

[config]
publish_run_status = false
run_status_context = "pr-agent"   # the status name shown on the commit

Behaviour change

Configuration Result
shipped default nothing — byte-identical to today
publish_run_status = true pending when the PR is opened, then success or failure
a command returns False or raises failure, and the remaining commands still run
provider without statuses no-op, no error

Testing

$ PYTHONPATH=. pytest tests/unittest
3698 passed, 1 skipped, 1 xfailed, 91 warnings in 53.69s

New file tests/unittest/test_run_status_acknowledgment.py (13 tests), written first (12 failed /
1 passed before, 13 passed after). Covers all three states on GitHub, the configured context,
description truncation, a missing commit SHA, an API failure, GitLab's failed mapping, and the
four wiring outcomes including the default-off control.

Also checked: ruff check clean on every file touched.

Risk / compatibility

Nothing happens unless the setting is turned on. Every provider call is wrapped, so a repository
where the token cannot write statuses logs a warning and continues.

Scope

Wired into the GitHub automatic-command runner in this PR. The primitive lives on the base
provider, so the GitLab and Gitea runners are a two-line follow-up each.

Copilot AI lite review requested due to automatic review settings September 6, 2026 09:07

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@github-actions github-actions Bot added the feature 💡 label Sep 6, 2026

@IsmaelMartinez IsmaelMartinez left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Thanks, and the gap is real: the check run added in #2492 only ever publishes completed/neutral, so there is no in-progress signal today.

I cannot take this as written though. propagate_tool_errors is false by default, so a review that fails internally is swallowed at pr_reviewer.py:347 and handle_request still returns True, which publishes success. And because _perform_auto_commands_github sets is_auto_command, the failure comment at line 358 is suppressed as well, so a failed automatic review gets no comment and a green tick.

Before fixing that, a design question. Rather than a second mechanism in the checks area, could this move the existing check run from completed to in_progress and back? Two parallel ways to report on the same commit seems worse than extending the one that already merged.

… as a failed run

propagate_tool_errors is false by default, so a tool that catches its own error
returns normally and handle_request answers True. The run status then read success
on a pull request that never got its review. Record the swallowed failure in the
run details and have the auto-command runner read it back.
@dwin-gharibi
dwin-gharibi force-pushed the feat/immediate-pr-acknowledgment branch from 2baf9fe to f694088 Compare September 6, 2026 17:16
@qodo-code-review

qodo-code-review Bot commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Code Review by Qodo

Grey Divider

Sorry, something went wrong

We weren't able to complete the code review on our side. Please try again manually by commenting /agentic_review on this PR.

Grey Divider

Qodo Logo

@IsmaelMartinez

Copy link
Copy Markdown
Collaborator

Thanks for the fix at f694088, that closes the swallowed-error half. The open question is still the shape: move the #2492 check run through in_progress and back rather than add a commit status beside it, so there is one mechanism on the commit. If the status API is the better fit for a reason I am missing, say so and I will review the head as it stands.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants