A base could follow a GitLab project: its markdown files, then its issues and merge requests

Read ADR 0013 and the agreed shape in #1303, then inspect the existing github_repo and github_issues sources. Start with the public GitLab fixture named in the issue and its recorded API responses. Done means deciding whether to introduce a shared issue-provider shape and implementing the two proposed GitLab sources with the specified pagination, file handling, token use, and tracker history.

What you are trying to do

This follows up #1303, where we agreed GitLab would get its own issue. Several of the repositories I work with are private projects on gitlab.com. I'd like a base to follow them the way github_repo (#1325) and github_issues follow GitHub: the markdown files at the head of the default branch, and the issues and merge requests with their history.

What would help

Two PRs, files first, in the shape agreed in #1303: gitlab.com with a token, marked "not verified against self-managed".

1. gitlab_repo, the same shape as github_repo. Each path is one document, keyed by path and dated by the last commit that touched it. Unchanged files aren't fetched again, and identical files go in once. It has the same include and exclude globs and size cap. I checked the API against gitlab.com, and three things differ from GitHub:

The tree is paged. GET /projects/:id/repository/tree?recursive=true&pagination=keyset returns up to 100 entries per page instead of one call, and there's no truncated flag. A page cap would make the round truncated, and a truncated round marks nothing "Not in source", as for GitHub.
Tree entries have the blob SHA (id) but no size. The unchanged check works as it does for GitHub. For a new or changed file, HEAD /projects/:id/repository/files/:path?ref=… returns X-Gitlab-Size before anything is downloaded, so the size cap holds.
So a new or changed file costs three calls instead of two: the HEAD, then GET /projects/:id/repository/commits?path=…&per_page=1 for the date (committed_date), then GET /projects/:id/repository/blobs/:sha/raw for the bytes. committed_date carries milliseconds (2026-10-05T14:30:00.000+00:00), which would be cut to the second, as ADR 0013 asks.

The token is a personal, project or group access token with read_api. GitLab accepts it as Authorization: Bearer … (checked with a personal access token), so it can reuse auth_header, which is already sealed through SOURCE_SECRET_KEYS.

2. gitlab_issues: issues and merge requests. Each issue or merge request becomes one document, with its notes and its state, label and milestone events in the body. This would be the third tracker, the point at which ADR 0013 says to reconsider the issue-provider shape. GitLab fits the GitHub shape rather than Jira's: updated_after works like since, and events are fetched per ticket, like /issues/{n}/events. Before writing it, I'd like to settle here whether that third tracker justifies a shared shape, or whether it stays a third reader like the other two.

My own projects are private, so I've set up a public project for the tests: https://gitlab.com/QuintinBotes/utopia-gitlab-fixture. Every file in it is a test case, across two commits with different dates:

markdown in nested folders;
an identical copy of one file;
an empty file;
a 3,368-byte file to test against a small size cap;
a hidden folder, node_modules and vendor;
a symlink;
a non-markdown file.

Tests would use responses recorded from it, so they can be re-recorded whenever the API changes. For the second PR, I'd add an issue and a merge request with comments and label and state changes there too.

What you do today instead

A script on my machine reads each project's clone, takes the markdown at the default branch, and pushes it through an api source, keyed by path and dated with git log -1 per file. Issues and merge requests don't come in at all.

A base could follow a GitLab project: its markdown files, then its issues and merge requests

Assessment

Research direction

Description

What you are trying to do

What would help

What you do today instead

Getting set up

First steps

More from deeplethe/utopia

Similar issues

A base could follow a GitLab project: its markdown files, then its issues and merge requests

Is something wrong?

Assessment

Research direction

Description

What you are trying to do

What would help

What you do today instead

Getting set up

First steps

More from deeplethe/utopia

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Similar issues

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Get new issues in your inbox