Skip to content

Forgejo integration#11111

Merged
neubig merged 34 commits intoOpenHands:mainfrom
johba37:forgejo-integration-rebased
Dec 27, 2025
Merged

Forgejo integration#11111
neubig merged 34 commits intoOpenHands:mainfrom
johba37:forgejo-integration-rebased

Conversation

@johba37
Copy link
Copy Markdown
Contributor

@johba37 johba37 commented Sep 25, 2025

  • This change is worth documenting at https://docs.all-hands.dev/
  • Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

End-user friendly description of the problem this fixes or functionality this introduces.
Brings Forgejo (Codeberg/self-hosted) into parity with our GitHub/GitLab integrations so users can browse repos, fetch issues/PRs, and collaborate on Forgejo instances within OpenHands.


Summarize what the PR does, explaining any non-trivial design decisions.

  • Builds on the earlier (stale/closed) effort in Add Forgejo integration similar to GitHub and GitLab integrations #8418 to finish Forgejo support.
  • Wires Forgejo into ProviderType, provider mappings, and resolver factories while removing Codeberg-only assumptions via configurable base URLs/env var overrides.
  • Refactors the Forgejo client into a mixin-based architecture (base, branches, repos, features, prs, resolver) matching our GitHub/GitLab layout, which keeps shared HTTP logic isolated and makes future feature work modular.
  • Implements the missing PR operations (create/request reviewers) plus richer resolver helpers (issue/PR comments and grouped review threads).
  • Updates unit tests to exercise the new mixin assembly and PR helpers under both the service layer and resolver factory.

Link of any specific issues this addresses:
#9354

@johba37 johba37 mentioned this pull request Sep 25, 2025
@johba37 johba37 force-pushed the forgejo-integration-rebased branch 15 times, most recently from 8cd711a to 29d684e Compare September 25, 2025 19:03
@erkinalp
Copy link
Copy Markdown
Contributor

erkinalp commented Oct 9, 2025

Great to see this effort continuing to be pursued.

@johba37 johba37 force-pushed the forgejo-integration-rebased branch from 29d684e to cbd2365 Compare October 11, 2025 17:45
@johba37
Copy link
Copy Markdown
Contributor Author

johba37 commented Oct 11, 2025

Great to see this effort continuing to be pursued.

so how to get a reviewer?

@erkinalp
Copy link
Copy Markdown
Contributor

@mamoodi Can you review this PR?

@mamoodi
Copy link
Copy Markdown
Collaborator

mamoodi commented Oct 13, 2025

@mamoodi Can you review this PR?

I can only properly review doc updates. But let me post this in Slack and see if I can get some eyes on this. Thanks!

openhands-agent and others added 4 commits December 21, 2025 10:43
…nd host on save\n\nAvoids subtle validation failures due to accidental spaces in inputs.\n\nCo-authored-by: openhands <openhands@all-hands.dev>
…ab, bitbucket, azure devops, forgejo) on save\n\nPrevents validation issues from pasted tokens with leading/trailing spaces.\n\nCo-authored-by: openhands <openhands@all-hands.dev>
…whitespace

Fix/forgejo trim token whitespace
@neubig neubig requested review from neubig and removed request for hieptl, malhotra5 and tofarr December 22, 2025 21:04
@neubig
Copy link
Copy Markdown
Contributor

neubig commented Dec 22, 2025

I'll try to play with this one over the winter break!

@MrGeorgen
Copy link
Copy Markdown
Contributor

MrGeorgen commented Dec 23, 2025

@neubig i made a PR to the branch of this PR that implements the missing UI for forgejo and some other fixes. johba37#1

I found an issue that I have not fixed so far. If you ask OpenHands to open a PR, it says it does not have the forgejo token. However if you tell OpenHands that it has the token already, it sometimes opens the PR correctly. I tried to let OpenHands fix this however it did not work (see PR MrGeorgen#3).

@enyst
Copy link
Copy Markdown
Collaborator

enyst commented Dec 26, 2025

I found an issue that I have not fixed so far. If you ask OpenHands to open a PR, it says it does not have the forgejo token. However if you tell OpenHands that it has the token already, it sometimes opens the PR correctly. I tried to let OpenHands fix this however it did not work (see PR MrGeorgen#3).

IMHO this sounds like an issue with what the agent knows, a prompt tweak might fix it. It seems to me unnecessary for this PR, though, good for a follow up when we understand better what's up.

I think maybe PRs don't have to do everything at once to be mergeable 😅 , or we'd be way too slow to do anything. Just a thought, please feel free to let it slide. I really appreciate all the work on this, in any PRs it's in!

@neubig neubig requested a review from amanape as a code owner December 27, 2025 16:09
neubig and others added 7 commits December 27, 2025 11:12
Co-authored-by: openhands <openhands@all-hands.dev>
- Fix PROVIDER_TOKENS_SET -> provider_tokens_set case bug in git-settings.tsx
- Add httpx_verify_option() for TLS verification in Forgejo service (supports self-signed certs)
- Revert unrelated changes to core/main.py, runtime plugins (jupyter, vscode), and files.py

Co-authored-by: openhands <openhands@all-hands.dev>
- Move ForgejoTokenInput inside gap-4 container for consistent spacing
- Update git-settings tests to include forgejo provider in expected payloads

Co-authored-by: openhands <openhands@all-hands.dev>
Co-authored-by: openhands <openhands@all-hands.dev>
The factory is only called from IssueResolver which requires username,
so the type should reflect that contract rather than allowing None.

Co-authored-by: openhands <openhands@all-hands.dev>
Changed from All-Hands-AI/OpenHands to OpenHands/OpenHands to match
the URL used on main branch.

Co-authored-by: openhands <openhands@all-hands.dev>
- Changed 'else: # ProviderType.FORGEJO' to explicit elif with else raising ValueError
- Added missing Forgejo and Bitbucket support to update_existing_pull_request
- Changed 'else: # platform == ProviderType.GITLAB' to explicit handling
- Both send_pull_request and update_existing_pull_request now properly handle
  all providers and raise ValueError for unknown platforms

Co-authored-by: openhands <openhands@all-hands.dev>
Copy link
Copy Markdown
Contributor

@neubig neubig left a comment

Choose a reason for hiding this comment

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

OK, I looked through this PR and QAed, it looks great. Thanks so much to @johba37 for the contribution and really sorry that it took so long for us to merge it.

As evidence of the QA, attaching a few screenshots of me using it on my repo:

Image Image

It was able to submit a PR successfully.

Image

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

To justify why this is necessary:

Analysis of frontend/src/api/git-service/git-service.api.ts Changes

The changes are appropriate and necessary for the Forgejo integration. Here's the breakdown:

What Changed:

// Before (main branch):
getBranches(repository, page, perPage) {
  return get(`/api/user/repository/branches?repository=${encodeURIComponent(repository)}&page=${page}&per_page=${perPage}`)
}

// After (Forgejo PR):
getBranches(repository, page, perPage, selectedProvider?) {
  return get(`/api/user/repository/branches`, {
    params: { repository, page, per_page: perPage, selected_provider: selectedProvider }
  })
}

Why This Is Needed:

  1. Problem Being Solved: Without selected_provider, when fetching branches for a Forgejo repository, the backend would try GitHub first (and fail), then GitLab, etc. This causes unnecessary API calls and potential failures.

  2. Consistency with Existing Pattern: The selected_provider parameter already exists on these endpoints in main:

    • get_user_repositories (line 70)
    • search_repositories (line 140)
    • search_branches (line 174)

    It was missing only from get_repository_branches (line 243), which this PR correctly adds.

  3. Backend Changes: Commit de09fe3a4 added the corresponding backend support, threading selected_provider through to ProviderHandler.get_branches().

  4. Code Quality Improvement: The change from inline URL string concatenation to using a params object is cleaner and less error-prone.

Related Commits in the PR:

  • de09fe3a4 - Added selected_provider to backend endpoint
  • ef6543a3e - Fixed ruff B008 linter errors by using Annotated[..., Query()] pattern (required because Query(default=None) as a default argument triggers the B008 rule about mutable default arguments)

Verdict: These changes are appropriate and follow existing patterns in the codebase.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Analysis of openhands/server/routes/git.py Changes

There are two distinct changes in this file:

1. Annotated[..., Query()] Pattern (commit ef6543a) - NECESSARY

Changed from:

selected_provider: ProviderType | None = None,

To:

selected_provider: Annotated[ProviderType | None, Query()] = None,

Why it's necessary: This fixes a ruff B008 error. The B008 rule warns against mutable default arguments in function calls. When you use Query() directly as a default value, it creates a new Query object at function definition time, which ruff flags. Using Annotated[..., Query()] is the modern FastAPI pattern that avoids this issue.

This change was made to 3 existing parameters (selected_provider in get_user_repositories, search_repositories, and search_branches).

2. Adding selected_provider to get_repository_branches (commit de09fe3) - NECESSARY for Forgejo

async def get_repository_branches(
    repository: str,
    page: int = 1,
    per_page: int = 30,
    selected_provider: Annotated[ProviderType | None, Query()] = None,  # NEW
    ...
)

Why it's necessary: This parameter was added to prevent GitHub fallback when fetching branches for Forgejo repositories. Without this, the system would try GitHub first and fail before falling back to Forgejo. This matches the pattern already used in other endpoints (search_repositories, search_branches).

Summary

Change Can Revert? Reason
Annotated[..., Query()] on existing params No Fixes ruff B008 linting errors
New selected_provider param on get_repository_branches No Required for Forgejo to work without GitHub fallback

Both changes should stay. They're not unnecessary - one is a lint fix and the other is essential for proper Forgejo provider routing.

@neubig neubig merged commit f8e4b55 into OpenHands:main Dec 27, 2025
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants