feat(status): acknowledge a pull request the moment automatic commands start - #3091
dwin-gharibi wants to merge 4 commits into
Conversation
…tic commands start
…run status acknowledgment
IsmaelMartinez
left a comment
There was a problem hiding this comment.
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.
2baf9fe to
f694088
Compare
|
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. |
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)wherestateispending,successorfailure. The base implementation returnsFalse, so providers without acommit-status API are a no-op.
create_status), truncating the description to the140 characters GitHub accepts.
failureto 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_githubpublishespendingbefore the command loop andsuccess/failureafter it, tracking both a command that returnsFalseand one that raises.Configuration, off by default:
Behaviour change
publish_run_status = truependingwhen the PR is opened, thensuccessorfailureFalseor raisesfailure, and the remaining commands still runTesting
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
failedmapping, and thefour wiring outcomes including the default-off control.
Also checked:
ruff checkclean 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.