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, associate the Gitea repository with the intended environment and enable Review Code automation for that target. Open or reopened PR events enqueue initial review tasks. PR sync events enqueue delta reviews. @roomote comments on Gitea pull requests route into the existing PR owner task when possible, or enqueue a new review task.

​
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.

​
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