Skip to main content
Source-control providers give Roomote access to the repositories where your team’s work happens. Roomote uses source control to sync repositories into environments, clone code inside task sandboxes, push branches, open or update pull requests, and respond to review events or comments when the provider supports them.

​
Supported providers

​
Setup checklist

Before connecting source control, make sure your deployment has:
  1. a stable public HTTPS URL for callbacks and webhooks
  2. an admin or bot identity with access to the repositories Roomote should use
  3. provider credentials saved in setup, Settings, or deployment environment variables
  4. at least one environment that can use the synced repositories
After setup, verify that Roomote can:
  • list the expected repositories
  • create or update an environment from a repository
  • clone the repository inside a task sandbox
  • push a branch or open a reviewable change when the task finishes

​
Attribution on pull requests and commits

Roomote keeps human-readable attribution inside private repositories. For public repositories, it uses the task participant’s linked source-control username when one is available. If Roomote cannot resolve a linked username, the pull request or merge request says only that it was created by Roomote. Roomote never derives public attribution from an account email address. Commit emails use the source-control provider’s noreply identity when available, or the Roomote identity otherwise. A workspace containing any public or unresolved repository uses the public-safe identity for all new commits because Git author configuration applies across the workspace. Linked GitLab and Gitea accounts retain the username verified by that provider, scoped to the configured source-control host. Bitbucket does the same only when its profile API returns a username; a nickname is not treated as a public handle. Azure DevOps accounts retain their verified display name for Settings and private-repository context, but public attribution remains generic because Azure DevOps does not provide a stable non-email public handle. GitLab.com can also provide a verified noreply commit identity; other non-GitHub providers use Roomote as the Git author for public work. Existing account links pick up verified profile attribution after their OAuth token refreshes or after the account is linked again. Changing a repository from private to public does not rewrite existing Git history. Roomote sanitizes a legacy named attribution line the next time it updates an open public pull request.

​
Pull request review comments

When Review Code finds an issue on a changed line, Roomote posts the finding as an inline comment on GitHub, GitLab, Gitea, Bitbucket, and Azure DevOps. It replies to an existing thread when the provider supports threaded replies and the same lines are already under discussion. On Gitea, that reply becomes a pull request comment that references the original thread. Roomote can anchor new findings to added, changed, or deleted lines. If a provider rejects an inline location, Roomote retries with the current diff and then includes the finding with a file and line reference in the review summary. On later sync reviews, Roomote resolves its inline thread when the flagged issue is clearly fixed and the provider supports thread resolution.

​
Public URLs

Use the same deployment URL across source-control callbacks and webhooks. If the public URL changes, update the provider app settings and restart Roomote with the matching deployment URL before testing again. Local development commonly uses R_PUBLIC_URL. Production deployments usually derive callbacks from the public app URL configured by the installer or Compose environment. During setup, Roomote shows the exact callback URL for the selected provider. Copy that value into the provider application instead of constructing it by hand.

​
Remove a provider configuration

Admins can remove any saved source-control provider from Settings > Source Control. Roomote first attempts to remove external webhooks, then deletes the saved database configuration and any provider OAuth connection, then disconnects that provider’s synced repositories. Removing a delegated Azure DevOps configuration also unlinks the account used by that connection. Process environment variables are not removed. If the provider is configured through deployment environment variables, remove or replace those values in the deployment configuration too. Roomote reports warnings when an external hook or OAuth cleanup cannot be completed, so review those warnings before reconnecting the provider.