Summary
We need GitLab implementations for three provider methods so that Seer's PR-context-gathering agent tools can work on GitLab. These tools let the Seer Explorer agent read context about a PR/MR (check runs, reviews, review comments) before iterating on it. They are currently GitHub-only, gated on the GitLab provider lacking these methods.
- Agent tools PR (consumer): getsentry/seer#6763
ScmRepoClient methods PR (the wrappers calling these provider methods): getsentry/seer#6762
The GitHub provider already implements all three. The GitLab provider (src/scm/providers/gitlab/provider.py) does not.
Methods to add on the GitLab side
1. list_check_runs_for_ref — needed, cleanly feasible
Backs the agent's get_pr_failed_check_runs tool, which lists the latest check runs for a commit ref so the agent can see which CI checks failed on its PR.
GitLab equivalent: List the statuses of a commit — GET /projects/:id/repository/commits/:sha/statuses (https://docs.gitlab.com/api/commits/). It returns status, name, description, target_url, created_at, finished_at, allow_failure, etc., and an all param that maps to our timestamp_filter latest-vs-all. The GitLab provider already has check-run mapping for create_check_run/get_check_run, so that mapping can be reused.
2. list_pull_request_reviews — needed, but only an approximation is possible
Backs the agent's get_pr_reviews tool, which lists submitted reviews on a PR.
GitLab has no GitHub-style review objects — there's no review with a state (APPROVED/CHANGES_REQUESTED/COMMENTED) and a body. The closest is merge request approvals — GET /projects/:id/merge_requests/:iid/approvals (https://docs.gitlab.com/api/merge_request_approvals/), which only captures who approved and when. An implementation could map approvals to approved-only reviews, but "changes requested" / "commented" reviews cannot be represented. Flagging this as a semantic gap: full parity isn't achievable, and we should agree on whether an approvals-only approximation is acceptable here.
3. get_review_comments — needed, but not portable as-is
Backs the agent's get_pr_review_comments tool, which lists the inline diff comments belonging to a single review (review_id).
Since GitLab has no review objects, there is no review_id to key on, so the GitHub-shaped endpoint can't be ported directly. GitLab's inline diff comments live as notes inside discussions (already exposed via get_pull_request_review_threads). Options: (a) change the contract to "all MR diff comments" backed by discussions/notes, or (b) leave it unsupported on GitLab. Would like input on the preferred direction.
Summary
We need GitLab implementations for three provider methods so that Seer's PR-context-gathering agent tools can work on GitLab. These tools let the Seer Explorer agent read context about a PR/MR (check runs, reviews, review comments) before iterating on it. They are currently GitHub-only, gated on the GitLab provider lacking these methods.
ScmRepoClientmethods PR (the wrappers calling these provider methods): getsentry/seer#6762The GitHub provider already implements all three. The GitLab provider (
src/scm/providers/gitlab/provider.py) does not.Methods to add on the GitLab side
1.
list_check_runs_for_ref— needed, cleanly feasibleBacks the agent's
get_pr_failed_check_runstool, which lists the latest check runs for a commit ref so the agent can see which CI checks failed on its PR.GitLab equivalent: List the statuses of a commit —
GET /projects/:id/repository/commits/:sha/statuses(https://docs.gitlab.com/api/commits/). It returnsstatus,name,description,target_url,created_at,finished_at,allow_failure, etc., and anallparam that maps to ourtimestamp_filterlatest-vs-all. The GitLab provider already has check-run mapping forcreate_check_run/get_check_run, so that mapping can be reused.2.
list_pull_request_reviews— needed, but only an approximation is possibleBacks the agent's
get_pr_reviewstool, which lists submitted reviews on a PR.GitLab has no GitHub-style review objects — there's no review with a
state(APPROVED/CHANGES_REQUESTED/COMMENTED) and a body. The closest is merge request approvals —GET /projects/:id/merge_requests/:iid/approvals(https://docs.gitlab.com/api/merge_request_approvals/), which only captures who approved and when. An implementation could map approvals to approved-only reviews, but "changes requested" / "commented" reviews cannot be represented. Flagging this as a semantic gap: full parity isn't achievable, and we should agree on whether an approvals-only approximation is acceptable here.3.
get_review_comments— needed, but not portable as-isBacks the agent's
get_pr_review_commentstool, which lists the inline diff comments belonging to a single review (review_id).Since GitLab has no review objects, there is no
review_idto key on, so the GitHub-shaped endpoint can't be ported directly. GitLab's inline diff comments live as notes inside discussions (already exposed viaget_pull_request_review_threads). Options: (a) change the contract to "all MR diff comments" backed by discussions/notes, or (b) leave it unsupported on GitLab. Would like input on the preferred direction.