Rindo

GitHub and GitLab

Connect a repository so commits, branches and pull requests link to tasks by key, a merge can move a task, and a review agent can be called in.

Last updated 2026-10-10

A project connects to one or more repositories on GitHub or GitLab — cloud or your own server. From then on a task key in a commit message, a new branch’s name, or a pull request’s title or branch links to the task; a merge can move the task; and a project agent can be called in to review pull requests.

Connect a repository

An Admin opens Settings → Integrations → Git and chooses Connect repository:

  • Provider — GitHub or GitLab. Repository — owner/name on GitHub; the full project path on GitLab.
  • API base URL — leave empty for github.com or gitlab.com. For GitHub Enterprise Server give https://HOST/api/v3; for self-managed GitLab https://HOST/api/v4. It must be a public https address that app.rindo.io can reach.
  • Personal access token — optional, with the repo scope on GitHub (read:org too for a repository under an organisation) or the api scope on GitLab. It is stored encrypted and never shown again. Without one, only a repository the provider serves without signing in can be checked, and review dispositions are not mirrored back.
  • When a pull request merges — a status to move the task to, or Do nothing.
  • Review agent — one of the project’s agents, or None.

Saving checks that the repository is reachable; if it is not, nothing is saved. The provider and the repository are fixed from then on — to repoint, disconnect and connect again. Each connection also makes a row on the project’s Webhooks page, where every delivery Rindo accepts is logged.

Add the webhook

Rindo never creates the webhook for you. Once the connection is saved it shows the Payload URL — https://app.rindo.io/webhooks/git/<id>, listed later under Receiver endpoints too — and, one time only, the Webhook secret. Copy it; it is not shown again (Rotate secret… issues a new one, and deliveries signed with the old one are refused until you update the provider).

  • GitHub → Settings → Webhooks → Add webhook. Paste the payload URL, set the content type to application/json, paste the secret, and select Pushes, Branch or tag creation, Branch or tag deletion and Pull requests. If you set a review agent, select Pull request reviews as well — that is what calls the agent back when a review is submitted.
  • GitLab → Settings → Webhooks → Add new webhook. Paste the URL and the secret token, and tick Push events and Merge request events. GitLab can also sign deliveries: Webhook signing token… on the connection generates one or takes GitLab’s.

Deliveries land on Settings → Integrations → Webhooks under Event log — pending, processed, skipped or failed — and are kept for the period the page states. A delivery with a wrong signature is refused before it reaches the log. A failed delivery is final: Rindo does not retry it, and a redelivery from GitHub carries the same delivery id and is not processed again.

One rule: a task key — ACME-12, in any case, not preceded by a letter or digit and not followed by another digit — found in

  • a commit message on a push (on GitLab, the first twenty commits of a large push);
  • a branch name when the branch is created (deleting the branch removes the link);
  • a pull request’s title or head branch (not its description, and never a comment); editing the title away drops the link unless the head branch still names the task.

Only the connected project’s own tasks are matched. The task page gains a Code section — branches, commits and pull requests with their state, Draft, Open, Merged or Closed — visible to everyone in the project and absent until something links. Watchers of the task hear PR #N merged in their Inbox. A release lists the pull requests of its linked tasks.

Move the task on merge

With When a pull request merges set, each task the merged pull request names is moved to that status, checked against the workflow like any other move. A move the workflow does not allow is skipped and nothing is reported; a task already in that status is left alone. The audit trail records the move as auto-transitioned, attributed to the Admin who made the connection.

Code review by an agent

With a Review agent set, Rindo calls it when a linked pull request is opened or marked ready, and again when a review is submitted (on GitLab, when the merge request is approved) — provided the agent is active, the project can take agent jobs, and it is under its queued-job limit. The agent reads the pull request with its own tools and can file a Code review pass in Reviews, with findings anchored at a file and line, a link to the review on the provider, and rounds that follow one another.

Rindo does not import what human reviewers write on GitHub or GitLab. Review passes are filed over MCP, normally by an agent; the app does not create them.

Each finding takes a Disposition — fixed, wont_fix or invalid — with an optional response, from a Member or an agent. When the finding is tied to the provider’s review comment and the connection holds a token, Rindo then mirrors it to the provider: fixed and invalid resolve the review thread, wont_fix replies with your response.

Several projects, one repository

Connections belong to a project. A repository that serves two projects is connected twice, with a webhook for each, and each delivery links only its own project’s tasks.

Disconnect

Disconnect… stops syncing, deletes the connection’s event log, and removes the links it made — commits, branches and pull requests leave the task pages and the release pages. The tasks themselves and their history stay.

Who can do what

Connecting, editing, disconnecting, rotating the secret and reading the event log take Admin, in the app or over REST; there is no MCP tool for them. The Code section on a task is read by everyone. A disposition takes Member, agents included.