Summary
We use Steampipe for change-management / audit exports: merged PR/MR populations by project, branch, and date range, including who approved each change.
On GitHub (turbot/github), this works via a SQL join to github_pull_request_review (state = 'APPROVED'). On GitLab (theapsgroup/gitlab), gitlab_merge_request covers merged MR metadata, but there is no table or column for approver identity—only merged_by_username, which is not the same as approvers.
We would value MR-level approval data exposed in SQL. This is a contribution-friendly request; happy to help test on self-managed GitLab if useful.
What is missing (vs GitHub)
| Need |
GitHub (turbot/github) |
GitLab plugin today |
| Merged changes in window |
github_pull_request |
gitlab_merge_request |
| Who approved |
github_pull_request_review (author_login, state = 'APPROVED') |
Not available |
| Join keys |
repository_full_name + number |
Would need project_id + iid |
Insufficient substitutes on gitlab_merge_request:
reviewers / assignees (jsonb) — assignment, not approval
merged_by_username — who merged, not who approved
approvals_before_merge — rule count, not usernames
Proposed addition
Preferred: new table gitlab_merge_request_approval (one row per approver per MR), keyed by project_id + merge_request_iid (required qualifiers, consistent with gitlab_merge_request).
Columns from Merge request approvals API — GET /projects/:id/merge_requests/:merge_request_iid/approvals:
approver_id, approver_username, approver_name, approved_at (from approved_by[])
Alternative: approved_by jsonb (or similar) on gitlab_merge_request — simpler, weaker for joins/aggregations.
This differs from #80 (project-level approval rules), not per-MR approved_by.
Target SQL (after feature exists)
SELECT
mr.iid,
mr.merged_at,
mr.author_username,
mr.merged_by_username,
STRING_AGG(DISTINCT a.approver_username, ',' ORDER BY a.approver_username) AS approved_by
FROM gitlab_merge_request mr
LEFT JOIN gitlab_merge_request_approval a
ON a.project_id = mr.project_id AND a.merge_request_iid = mr.iid
WHERE mr.project_id = $1
AND mr.state = 'merged'
AND mr.merged_at BETWEEN $2 AND $3
GROUP BY 1, 2, 3, 4;
GitHub equivalent today:
LEFT JOIN github_pull_request_review rev
ON rev.repository_full_name = pr.repository_full_name
AND rev.number = pr.number
AND rev.state = 'APPROVED'
Data is available outside Steampipe
The GitLab REST API and GitLab CLI (glab) already expose this, e.g.:
glab api "projects/<project_id>/merge_requests/<iid>/approvals"
glab mr view <iid> -R <namespace/project>
We currently enrich exports with per-MR API/glab calls. Native plugin support would avoid N+1 scripts and match our GitHub Steampipe workflow.
Use case
Audit and compliance workflows that require CSV (or SQL) evidence of merged changes with approver identities, not only merger and assigned reviewers—especially when exporting hundreds of MRs across many projects on a schedule.
Thank you for maintaining this plugin.
Summary
We use Steampipe for change-management / audit exports: merged PR/MR populations by project, branch, and date range, including who approved each change.
On GitHub (
turbot/github), this works via a SQL join togithub_pull_request_review(state = 'APPROVED'). On GitLab (theapsgroup/gitlab),gitlab_merge_requestcovers merged MR metadata, but there is no table or column for approver identity—onlymerged_by_username, which is not the same as approvers.We would value MR-level approval data exposed in SQL. This is a contribution-friendly request; happy to help test on self-managed GitLab if useful.
What is missing (vs GitHub)
turbot/github)github_pull_requestgitlab_merge_requestgithub_pull_request_review(author_login,state = 'APPROVED')repository_full_name+numberproject_id+iidInsufficient substitutes on
gitlab_merge_request:reviewers/assignees(jsonb) — assignment, not approvalmerged_by_username— who merged, not who approvedapprovals_before_merge— rule count, not usernamesProposed addition
Preferred: new table
gitlab_merge_request_approval(one row per approver per MR), keyed byproject_id+merge_request_iid(required qualifiers, consistent withgitlab_merge_request).Columns from Merge request approvals API —
GET /projects/:id/merge_requests/:merge_request_iid/approvals:approver_id,approver_username,approver_name,approved_at(fromapproved_by[])Alternative:
approved_byjsonb (or similar) ongitlab_merge_request— simpler, weaker for joins/aggregations.This differs from #80 (project-level approval rules), not per-MR
approved_by.Target SQL (after feature exists)
GitHub equivalent today:
Data is available outside Steampipe
The GitLab REST API and GitLab CLI (
glab) already expose this, e.g.:We currently enrich exports with per-MR API/
glabcalls. Native plugin support would avoid N+1 scripts and match our GitHub Steampipe workflow.Use case
Audit and compliance workflows that require CSV (or SQL) evidence of merged changes with approver identities, not only merger and assigned reviewers—especially when exporting hundreds of MRs across many projects on a schedule.
Thank you for maintaining this plugin.