Repository navigation
[Bug] run-gemini-cli@v0 fetches wrong PR even when correct repo and PR number provided #251
Description
TL;DR
Description
The google-github-actions/run-gemini-cli@v0 action is failing to fetch pull request data for the correct repository and PR number, instead trying fallback PRs (1–6) and returning 404 errors.
Reproduction Steps
- Use Gemini workflow on
pull_requestevent, triggered for PR # inamber-ml/amber-ml. - Workflow log shows:
Then Gemini tries PRs 1 through 6 and finally saysunable to proceed with the code review.
Expected behavior
Gemini should fetch and review the exact PR it was triggered for—no arbitrary probing of PRs 1–6.
Observed behavior
Gemini disregards correct PULL_REQUEST_NUMBER and REPOSITORY, instead attempting PRs 1–6, all of which fail with 404.
Action YAML
jobs:
gemini-code-review:
runs-on: ...
env:
PULL_REQUEST_NUMBER: ${{ github.event.number }}
REPOSITORY: ${{ github.repository }}
steps:
- uses: google-github-actions/run-gemini-cli@v0
with:
gemini_cli_version: ${{ vars.GEMINI_CLI_VERSION }}
gemini_api_key: ${{ secrets.GEMINI_API }}
use_vertex_ai: false
use_gemini_code_assist: false
settings: |
{ ... }
prompt: |
Review this PR...Log output
Warning: Unexpected input(s) 'google_api_key', 'gemini_debug'
Error executing tool get_pull_request: ... pulls/<actual-number>: 404 Not Found
... retries PRs 1–6 with the same error
Additional information
No response
Activity
gemini-cli commentedon Aug 28, 2025
🤖 Hi @eshwarvijay, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.
michael-airspace commentedon Sep 2, 2025
Neat idea, but gemini is pulling random old PRs to review which don't match current PR.
hassib-ashouri commentedon Sep 3, 2025
How is this working on this repo; or is not working here too??
tleonhardt commentedon Sep 14, 2025
We have seen this problem as well. It appears to work correctly when a PR is first created. However, sometimes when a manual re-review is requested by posting a
@gemini-cli /reviewcomment in the PR, sometimes it works, but most of the time it goes out and reviews some old PR that has already been merged.Here is a specific example where we saw this recently in the
cmd2open-source Python library repo:TonyDowney commentedon Sep 22, 2025
Can confirm; I'm using this PR reviewer on a number of private repositories. In most, it works fine, but in one repository in particular, it consistently fails. Reviewing by opening a PR, or by explicitly requesting a review, returns the comment "🤖 Hi @TonyDowney, I've received your request, and I'm working on it now! You can track my progress in the logs for more details."
Then, either the action completes with no review posted anywhere, or I get an email notifying me that a review was done on a completely different (closed) PR.
I grabbed the logs from three runs (a clean run, a run where no review was posted, and a run where it reviewed the wrong PR) and all three sets of logs are identical, save some timestamps.
michalszelagsonos commentedon Oct 19, 2025
I was seeing this issue from time to time and I after updating the prompt in the review workflow with explicit repository and PR number instructions, it does the right thing every time.
Looks like the latest version on
mainnow includes the repository and PR number in the Input data section which is what I did to fix this. I suspect this is no longer a problem.MJjainam commentedon Dec 2, 2025
This must be fixed in the latest release.
Please re-open if this exists.