Skip to main content
Gitea support uses a deployment-owned OAuth application, instance URL, and authorized service account. An operator provides the application details, authorizes the service account, and syncs repositories from Settings. Repository sync can also create pull request webhooks, allowing Review Code automation and @roomote pull request comments to work for synced Gitea repositories. Use <public-url> below for your stable public Roomote URL.

​
Create a Gitea OAuth application and service account

Create a dedicated Gitea bot or service-account user and give it access to the organizations or repositories Roomote should use. New deployments use a Gitea 1.23+ OAuth application and a dedicated service account. Create the application with the redirect URI shown by Roomote:
Authorize it with the scopes read:user, read:repository, write:repository, write:issue, and read:organization. If Roomote should configure webhooks automatically, the service account also needs repository admin access for the synced repositories. Save the instance URL and OAuth application credentials in setup, deployment env vars, or local .env.local:
Optional values:
Roomote runs deployment operations as the authorized service account and uses that login for Git-over-HTTPS credentials. The setup flow asks for the Gitea instance URL and OAuth application credentials, then sends the operator through the authorization flow. Roomote generates the webhook secret during repository sync.

​
Sync repositories

After the Gitea values are available, open Settings, go to the Environments page, and use the Source Control section’s Gitea sync button. Roomote lists repositories from the Gitea API and stores them as Gitea repository rows. Gitea-backed tasks clone from the synced repository row, so sync must run before launching a Gitea-backed task. Worker tasks route selected Gitea HTTPS clone traffic through a local proxy instead of exposing OAuth tokens to task shells. After repository sync, Roomote best-effort creates or refreshes a repository webhook for each synced Gitea repository. The webhook target is:
If only loopback Roomote URLs are configured, webhook setup is skipped and repository sync still succeeds. If GITEA_WEBHOOK_SECRET is missing, Roomote generates and persists one as an encrypted deployment environment variable.

​
Enable review automation

Gitea pull request reviews use the same Review Code automation targeting model as GitHub and GitLab. After syncing repositories, enable Review Code automation. A repository doesn’t need an environment: reviews run in the environment that includes the repository when one exists, and otherwise on a plain checkout of the repository. Open or reopened PR events enqueue initial review tasks. PR sync events enqueue delta reviews. @roomote comments on Gitea pull requests and issues continue the Roomote session for that discussion, or start one when it does not exist.

​
CI Failure Triage

Associate the Gitea repository with an environment, configure the Manager Channel destination, and enable CI Failure Triage under Automations. When a Gitea Actions run fails on the repository’s default branch, Roomote launches one investigate-and-fix task for that repository. Failures outside the default branch are ignored. Manual Run now inspects the latest default-branch Actions run on the configured Gitea host only (self-managed deployments match repository host against GITEA_BASE_URL). Roomote reads a bounded tail of failed job logs with the deployment Gitea credential when the Actions API exposes them. Re-sync repositories after upgrading so webhooks include the workflow_run event.

​
Mention Roomote on pull requests and issues

Mention @roomote in a pull request or issue comment to talk to Roomote about it. Each pull request or issue is a Roomote session: Roomote reads the discussion, answers as a comment when no workspace is needed, and otherwise starts a task on the pull request’s head branch (or the issue’s repository) and reports back in the same discussion. Mention it again to redirect it, ask a follow-up, or steer a running task. The commenter must have a linked Gitea account. Ask for a review in the mention (for example @roomote review this) and Roomote runs the Review Code automation’s structured review on the current head, posts the findings on the pull request, and reports back in the same discussion.

​
Native pull request merging in sessions

Active members and admins can ask Roomote to read and merge a pull request in an active connected Gitea repository without starting a coding task. The bounded get_pull_request and merge_pull_request tools require repositoryFullName as owner/repo and a positive pullRequestNumber. Merging also requires the freshly read 40-character expectedHeadSha and can select merge, rebase, rebase-merge, or squash. Roomote merges only after an explicit request in the current human message. It reads the PR immediately before the mutation, passes the expected head commit to Gitea, leaves branch protections and permissions to Gitea, and reads the PR again before reporting success or retrying an ambiguous result. These tools do not expose branch/file writes, PR creation, or repository administration.

​
Current limits

Gitea OAuth applications accept one redirect URL. The setup flow configures the deployment callback, so the same OAuth application cannot also provide personal Gitea account linking. Pull-request comment mentions still use the Gitea webhook sender identity and never use the deployment service-account grant to identify the commenter.

​
Verify setup

  1. sync Gitea repositories from Settings
  2. create or update an environment from a synced repository
  3. start a small task and confirm Roomote can clone the repository
  4. open or update a pull request and confirm configured review automation runs
  5. optionally enable CI Failure Triage and push a failing default-branch Actions run to confirm triage starts