Repository inspection
Rivet provides a common read interface for GitHub.com, Bitbucket Cloud and GitLab.com. It identifies repositories, reads branches and pull/merge requests, and records checks and reviews without turning those observations into permission to deliver.
Inspect from your project
From a configured Git project, including a nested folder:
rivet repositories inspect
rivet repositories inspect --review=14The first command reads repository metadata. The second captures a pull request (GitHub/Bitbucket) or merge request (GitLab), its head commit, checks and review observations. Use the number from the selected repository.
If no saved publishing choice resolves multiple repositories, or several configured providers match, select them explicitly:
rivet repositories inspect --remote=upstream --provider=team-github --review=14 --jsonRivet does not assume that origin is the publishing target. An explicit --project=/absolute/project is available when running elsewhere. These commands perform network reads; rivet integrations check only reports configuration readiness.
Choose a publishing remote during setup
rivet setup previews locally configured Git remotes without network access. It proposes a single supported remote; when several names are available, it asks you to choose while applying setup in an interactive terminal. It never assumes origin is the publishing destination.
For an explicit choice, including scripts and JSON output:
rivet setup --remote=upstream
rivet setup --remote=upstream --writeThe preview shows the selected name and canonical repository URL. Applying setup stores them in repository.remote in .rivet/project.yaml. Other project settings, comments, provider files and project protocols are preserved. Local-only projects do not need a publishing remote.
Repository inspection and delivery preparation reuse this choice. A per-command --remote selects another destination for that operation without rewriting the saved choice or authorizing a write. Provider scope, review and merge approvals still apply separately.
If the saved remote disappears or points to a different repository, Rivet stops and asks you to review the choice again. Run setup with an explicit remote and inspect its preview before applying the replacement. Cancellation and conflicting changes during setup leave the selection unwritten.
Configure read access
Add an entry to the existing providers list in .rivet/providers.yaml:
- id: team-github
kind: git-ci
mode: read-only
transport: direct-api
capabilities: [repository-read, checks-read]
endpoint: https://api.github.com
projectIds: [your-project-id]
resourceIds: [your-team/your-repository]
credentials:
tokenEnv: RIVET_REPOSITORY_TOKENUse the project's actual ID and repository path. Set the referenced environment variable outside tracked configuration. The inspection CLI accepts a bearer token; it does not copy credentials from another application. Use a provider-issued token with read access to the selected resources. Tokens and credential values are excluded from output. For Bitbucket Cloud, use an OAuth or repository access token supported as a bearer credential; Atlassian user API tokens require Basic authentication and are not accepted by this CLI. See Bitbucket authentication.
| Provider | API endpoint | Repository scope example |
|---|---|---|
| GitHub.com | https://api.github.com | team/repo |
| Bitbucket Cloud | https://api.bitbucket.org/2.0 | workspace/repo |
| GitLab.com | https://gitlab.com/api/v4 | group/subgroup/repo |
Repository inspection requires repository-read; review inspection also requires checks-read. Disabled, out-of-project, out-of-repository and mismatched endpoint entries are not selected. Credentials must be present before any provider request. SSH or HTTPS Git remotes identify the repository; API reads use HTTPS.
Capability and qualification matrix
| Capability | GitHub.com | Bitbucket Cloud | GitLab.com |
|---|---|---|---|
| Repository and branch reads | Implemented | Implemented | Implemented |
| Pull/merge request identity and head SHA | Implemented | Implemented | Implemented |
| Commit checks/status observations | Implemented | Implemented | Implemented |
| Review observations | Implemented | Implemented | Implemented |
| Common interface writes | Unavailable | Unavailable | Unavailable |
| Separate HTTPS branch publication | Implemented, create-only | Implemented, create-only | Implemented, create-only |
| Separate native review creation | Implemented | Implemented | Implemented |
| Separate review title/description updates | Implemented | Implemented | Implemented |
| Separate native merge | Implemented for documented policies | Unavailable | Implemented for documented policies |
| Project-configured deployment | GitHub Actions executor | Unavailable | Unavailable |
| Public repository/branch read smoke | Passed | Passed | Passed |
| Public review inspection smoke | Passed on Rivet PR #14 | Pending | Pending |
| Authenticated sandbox and delivery qualification | Pending | Pending | Pending |
Public smoke checks on 2026-09-25 read Agilno-Tech/rivet, atlassian/atlassian-frontend-mirror and gitlab-org/gitlab without credentials. The GitHub check also inspected Rivet PR #14. These bounded reads do not establish private-repository access or complete delivery support.
The existing lower-level GitHub adapter retains its governed operations. The common repository interface is read-only. MCP and local CLI repository execution, custom API hosts, GitHub Enterprise, Bitbucket Data Center and self-managed GitLab are not qualified through this interface.
For local delivery preparation and the delivery service, see delivery lifecycle. Separate delivery executors support GitHub/Bitbucket PR and GitLab MR creation for already published verified branches, separately approved title/description updates for all three providers, plus GitHub/GitLab merges under documented bounded policy subsets. Create-only HTTPS branch publication is implemented separately for all three providers. Merge Bitbucket PRs manually in Bitbucket. Automatic merging is not available; live qualification remains pending.
Interpreting results
An inspection is a bounded observation at a particular time, not an atomic provider snapshot. Reviews and checks can change after they are read. It rechecks the request head after collecting related evidence and fails if that head changed. Checks from a different commit cannot count as current evidence. A review observation without a provider-supplied commit binding cannot prove approval of the current commit.
No checks is not a passing required-check gate. Observed approvals are not a substitute for branch protection, required reviewers, project policy or explicit delivery authority. Repository inspection does not merge, deploy, update a tracker or mark a Rivet task delivered.
Pagination is bounded. Access errors, missing branches, rate limits, malformed results and inconsistent snapshots stop inspection rather than producing partial success. Retry after correcting access or waiting for provider availability; inspect again after a new commit.