This is a generic bot acct
# proj-sdk
w
This is a generic bot acct
I don't think it should be the one we use for reviews
I'd create a new one
thanks on a stick 1
we use it for internal automation
c
We could also consider just create an openhands-reviewer github app though 🤔 @nutritious-balloon-65098 please checkout OpenHands/software-agent-sdk, understand how the PR review workflow is implemented, then tell me, if it make sense to use a github app instead of token? If so, what do we need to do for that
n
I'm on it! Xingyao Wang can track my progress here.
## Summary I analyzed the PR review workflow implementation in
OpenHands/software-agent-sdk
to answer your question about whether it makes sense to use a GitHub App instead of a Personal Access Token (PAT) for PR reviews. ### Answer: Yes, using a GitHub App (
openhands-reviewer
) makes sense.
### Key Findings: Current State: - The PR review workflow uses
secrets.ALLHANDS_BOT_GITHUB_PAT
from the
all-hands-bot
user account - This PAT is shared across ~13 workflows for various automation tasks (reviews, releases, stale management, etc.) Why a GitHub App is Better for Reviews: | Benefit | Impact | |---------|--------| | Clear identity | Reviews appear from
openhands-reviewer[bot]
instead of a shared bot user | | Separation of concerns | Keeps review identity separate from internal automation (
all-hands-bot
) | | Fine-grained permissions | App-specific, repo-scoped permissions | | Better security | Auto-expiring tokens (1hr) vs manual PAT rotation | | Higher rate limits | 5K/hour per installation vs shared user quota | What's Required: 1. Create
openhands-reviewer
GitHub App with permissions:
pull_requests: write
,
contents: read
,
issues: write
2. Store
APP_ID
and
PRIVATE_KEY
as repository secrets 3. Update
pr-review-by-openhands.yml
to use
actions/create-github-app-token@v1
to generate tokens 4. No code changes needed -
agent_script.py
reads
GITHUB_TOKEN
from env, agnostic to token source No changes were made to the repository - this was a research/analysis task only.
c
Related, I wonder if we could use a different LLM key for the reviewer agent, with its own limits. I'm thinking that maybe the worse that can happen to it is probably that a successful troll may have the reviewer do a bunch of things unrelated to review. Dunno what. Tell its life story on moltbook? 😅
It would be nice imho to not have "bot" in the name, it would be nice either "agent", or something related - "reviewer" is perfectly fine imho if it's for review-only
nod 1
c
I was wondering if we could build this "openhands-reviewer" Github App directly integrated into the SaaS (e.g., especially if you already give SaaS access to those repos, so it kinda makes sense)... @nutritious-balloon-65098 Please create a new issue for it - we should (1) implement cloud mode for the pr review bot, and then (2) integrate code review workflow to comment as a github app, similar to OpenHands Cloud
n
I'm on it! Xingyao Wang can continue tracking my progress here.
## Summary I completed the following tasks: ### 1. Analyzed the PR Review Workflow Implementation Reviewed the
OpenHands/software-agent-sdk
repository to understand how PR reviews work: - Current approach: Uses
secrets.ALLHANDS_BOT_GITHUB_PAT
(Personal Access Token from
all-hands-bot
user) - Key files:
.github/workflows/pr-review-by-openhands.yml
,
.github/actions/pr-review/action.yml
,
examples/03_github_workflows/02_pr_review/agent_script.py
- Finding: The PAT is used across ~13 workflows for various automation tasks, mixing reviewer identity with internal automation ### 2. Assessed GitHub App vs PAT Confirmed that using a GitHub App makes sense because: - Clearer identity (
openhands-reviewer[bot]
vs a real user) - Separates reviewer from internal automation (
all-hands-bot
) - Better security with auto-expiring tokens and fine-grained permissions - Can leverage existing SaaS repo access for users who already use OpenHands Cloud ### 3. Created GitHub Issue Created issue [#2082](https://github.com/OpenHands/software-agent-sdk/issues/2082) with a 3-phase implementation plan: 1. Phase 1: Implement cloud mode for PR review bot (authenticate via OpenHands Cloud API) 2. Phase 2: Integrate as GitHub App (
openhands-reviewer
) with proper permissions 3. Phase 3: Update workflows to support simple
mode: cloud
configuration --- No code changes were made - this was an analysis and issue creation task. The issue is now tracked at https://github.com/OpenHands/software-agent-sdk/issues/2082 for future implementation.
c
• Should this be the same GitHub App as OpenHands Cloud or a separate
openhands-reviewer
app? @nutritious-balloon-65098 please update the issue, we can first REUSE the same Github App first for simplicity
n
I'm on it! Xingyao Wang can continue tracking my progress here.
## Summary I completed the following tasks: ### 1. Analyzed PR Review Workflow Implementation - Reviewed the current implementation in
OpenHands/software-agent-sdk
- Found that PR reviews currently use
secrets.ALLHANDS_BOT_GITHUB_PAT
(a Personal Access Token from the
all-hands-bot
user) - Identified that this PAT is shared across ~13 workflows for various automation tasks ### 2. Assessed GitHub App Feasibility - Confirmed that using a GitHub App makes sense for PR reviews - Key benefits: clearer bot identity, better permissions control, leverages existing SaaS repo access, no additional app installation needed for Cloud users ### 3. Created GitHub Issue - Issue #2082: [Integrate PR Review Bot with OpenHands Cloud as GitHub App](https://github.com/OpenHands/software-agent-sdk/issues/2082) - Outlines a 3-phase implementation plan: 1. Implement cloud mode for PR review bot 2. Add SaaS backend support for the API endpoint 3. Update workflows to support
mode: cloud
option ### 4. Updated Issue Per User Feedback - Modified the issue to specify that we will reuse the existing OpenHands Cloud GitHub App for simplicity - This avoids requiring users to install another app and leverages existing repo permissions --- No code changes were made - this was purely an analysis and issue creation task. The issue is ready for discussion and implementation planning.
c
That would mean cloud runs instead of running in github actions?