Integrations

rupu plugs into your source host and your issue tracker so agents can read issues, work in repos, open pull requests, and comment back — across more than one platform at once.

Plug rupu into your stack

Integrations are how rupu reaches out beyond your laptop. Two connector families do the work, and both speak through rupu's single embedded MCP server so agents call the same typed tools regardless of which platform a call resolves to:

• Source control (SCM) — the RepoConnector. List and read repos, clone working trees, read files by ref, open pull requests / merge requests. Ships for GitHub and GitLab.
• Issue trackers — the IssueConnector. Fetch and list issues, comment, create, and transition state. Ships for GitHub Issues, GitLab Issues, Jira, and Linear.

Per-platform connectors absorb the vendor quirks — GitLab MR vs GitHub PR vocabulary, nested namespaces, rate-limit headers — so your agent files stay portable. An agent that reads scm.prs.diff and posts scm.prs.comment works against GitHub and GitLab unchanged.

Source control (SCM)

The RepoConnector handles everything repo-shaped. When a run targets a repo or a PR (not a bare issue), rupu clones the repo into a tempdir and runs the agent there; issue targets skip the clone and rely on read tools.

Run-targets pick a platform by prefix. PRs use #N on GitHub and !N on GitLab (GitLab's MR convention):

# repo working tree / PR / MR / issue
github:owner/repo            # repo
github:owner/repo#42         # PR 42
github:owner/repo/issues/123 # issue 123
gitlab:group/sub/project!7   # MR 7

The rupu repos CLI

List remote repos and manage the local repo registry (which checkout on disk maps to which repo ref):

rupu repos list                       # list repos across configured platforms
rupu repos attach github:owner/repo   # map a local checkout to a repo ref
rupu repos prefer github:owner/repo   # mark a checkout as the preferred path
rupu repos tracked                    # list locally tracked checkouts
rupu repos forget github:owner/repo   # forget a repo or one tracked path

Issue trackers

The IssueConnector family lets agents read and write tracker state. GitHub Issues and GitLab Issues are first-class on the issues.* tool surface and the rupu issues CLI; Jira and Linear ship connectors plus native trigger sources (polling and webhook — see Triggers).

GitHub Projects (v2) also drives the tracker workflow vocabulary: when an issue-backed project item's Status field changes, rupu maps it into portable issue.* aliases (e.g. issue.entered_workflow_state.ready_for_review). Projects native state mapping is webhook-only today — there is no poll_sources form for Projects yet.

The rupu issues CLI

Auto-detects the target repo from the cwd's git origin remote when --repo is omitted (currently GitHub / GitLab):

rupu issues list --state open --label triage   # list issues
rupu issues show github:owner/repo/issues/42    # full body + metadata
rupu issues run <workflow> #42                  # run a workflow against an issue

Run a workflow against an issue

rupu issues run is a convenience wrapper for the canonical form, which takes the issue ref as a positional run-target:

rupu workflow run <workflow> github:owner/repo/issues/42

Issue targets do not clone — the workflow runs in the current checkout and binds the issue's metadata into step prompts and when: filters as {{ issue.* }}:

How it fits together

The integrations close a loop. A new or labeled issue (or a tracker state change) wakes a workflow or an autoflow; rupu's agents do the work in a cloned checkout; the SCM connector opens a PR / MR with the result; and the issue connector posts a comment back so the conversation stays where your team already lives.

Cross-references: Autoflows drive the long-running issue→PR loop with branch ownership; Triggers cover the polling and webhook tiers that wake workflows on tracker and SCM events.

Auth for integrations

Each platform stores its credential in the OS keychain via one command. These are SCM / tracker credentials — distinct from model-provider auth (for that, see Providers & Auth).

rupu auth login --provider <github|gitlab|linear|jira> --mode <api-key|sso>
rupu auth status     # SCM + tracker rows appear automatically

• GitHub — classic PAT (repo, workflow, gist, read:org, read:user) or a device-code SSO flow.
• GitLab — PAT (api, read_user, read_repository, write_repository) or browser-callback PKCE SSO.
• Linear — API-key mode (used for polling / webhook normalization).
• Jira — API-key mode; store the credential as <email>:<api_token> in one secret for Jira Cloud polling.