gitlab

func (*Client) Capabilities ¶

func (c *Client) Capabilities() forge.Caps

Capabilities reports what GitLab accepts.

Multi-line suggestions have been on by default since 13.7; a project that turned them off rejects the comment, which surfaces as an API error rather than a silent miss.

func (*Client) Comment ¶

func (c *Client) Comment(ctx context.Context, ref forge.Ref, target, body string) error

Comment posts a note on an issue or merge request.

func (*Client) CreateDiffThread ¶

func (c *Client) CreateDiffThread(ctx context.Context, ref forge.Ref, mr int, dc forge.DiffComment) error

CreateDiffThread opens a discussion anchored to a place in the diff.

GitLab positions a comment with the three commits the diff was taken against plus the file and line. Without them the API takes the comment but drops it at the bottom of the discussion, which is a different comment from the one the reviewer wrote — so a missing position is refused here rather than posted somewhere else.

func (*Client) CreateThread ¶

func (c *Client) CreateThread(ctx context.Context, ref forge.Ref, target, body string) error

CreateThread starts a new discussion on an issue or merge request.

It is a discussion rather than a note so a review comment opens its own resolvable thread, which is what a reviewer expects to be able to close.

func (*Client) Epics ¶ added in v0.6.0

func (c *Client) Epics(ctx context.Context, s forge.Scope) ([]forge.Epic, error)

Epics lists the epics a scope can file issues under. Epics are a group-level feature, so a project Scope resolves to its immediate namespace group rather than the project itself.

Epics also need a licensed GitLab (Premium and above): on a Free instance the query errors, and this answers with nothing and no error — the same fail-quiet Statuses and workItems follow, and for the same reason: a board's epic legend should degrade gracefully, not fail the board. EpicsStrict is the propagating twin, for the epic picker, the same way StatusesStrict is for the status one.

resolveEpicParent, which resolves an epic title for a write rather than a listing, deliberately does not call this — see its own doc comment for why fail-quiet is wrong there.

func (*Client) EpicsStrict ¶ added in v0.6.0

func (c *Client) EpicsStrict(ctx context.Context, s forge.Scope) ([]forge.Epic, error)

EpicsStrict is Epics without the fail-quiet wrapping. It resolves the scope to a group the same way Epics does — an empty group is genuinely "nothing to ask," not a failure, so that case still answers (nil, nil) rather than an error — and then calls queryEpics directly, the same propagating query resolveEpicParent already relies on for the write path.

func (*Client) FileContent ¶

func (c *Client) FileContent(ctx context.Context, ref forge.Ref, path, rev string) ([]byte, error)

FileContent returns a file's bytes at a revision.

func (*Client) GroupIssues ¶

func (c *Client) GroupIssues(ctx context.Context, group string, f forge.IssueFilter) ([]forge.Issue, error)

GroupIssues lists issues across every project in a group — what GitLab's group issue board shows.

func (*Client) Issue ¶

func (c *Client) Issue(ctx context.Context, ref forge.Ref, id int) (forge.Issue, error)

Issue fetches one issue by its number.

func (*Client) Issues ¶

func (c *Client) Issues(ctx context.Context, ref forge.Ref, f forge.IssueFilter) ([]forge.Issue, error)

Issues lists issues in a project.

The status query is scoped to the project rather than to the issues, so when one is wanted it is started alongside the listing instead of after it: the board pays for the slower of the two rather than for both.

func (*Client) JobLog ¶

func (c *Client) JobLog(ctx context.Context, ref forge.Ref, jobID int) (io.ReadCloser, error)

JobLog returns a job's trace. GitLab hands back the whole trace as a buffer, so the reader needs no closing beyond satisfying the interface.

func (*Client) Jobs ¶

func (c *Client) Jobs(ctx context.Context, ref forge.Ref, pipelineID int) ([]forge.Job, error)

Jobs lists the steps of one pipeline, in the order GitLab reports them.

func (*Client) Labels ¶ added in v0.6.0

func (c *Client) Labels(ctx context.Context, s forge.Scope) ([]string, error)

Labels lists a project's or a group's labels.

func (*Client) Members ¶ added in v0.6.0

func (c *Client) Members(ctx context.Context, s forge.Scope) ([]forge.User, error)

Members lists a project's or a group's members, including those inherited from an ancestor group — the same "who could this be assigned to" set the provider's own web UI offers.

func (*Client) Merge ¶

func (c *Client) Merge(ctx context.Context, ref forge.Ref, mr int) error

Merge merges a merge request immediately.

It deliberately does not set auto-merge: a stack merges under the user's explicit, confirmed keypress, and a queued merge that lands later would take the decision out of their hands.

func (*Client) MergeRequest ¶

func (c *Client) MergeRequest(ctx context.Context, ref forge.Ref, mr int) (forge.MergeRequest, error)

MergeRequest fetches one merge request by its number.

func (*Client) MergeRequestDiff ¶

func (c *Client) MergeRequestDiff(ctx context.Context, ref forge.Ref, mr int) (string, error)

MergeRequestDiff returns the merge request as a unified diff.

GitLab hands back one entry per file, carrying only the hunks — no "diff --git" or ---/+++ headers. Those are reconstructed here so the result is a real unified diff that any diff tool can read.

func (*Client) MergeRequests ¶

func (c *Client) MergeRequests(ctx context.Context, ref forge.Ref, f forge.MRFilter) ([]forge.MergeRequest, error)

MergeRequests lists merge requests in a project.

func (*Client) Milestones ¶ added in v0.6.0

func (c *Client) Milestones(ctx context.Context, s forge.Scope) ([]forge.Milestone, error)

Milestones lists the milestones a project's or a group's issues can be put on — its own, and every one inherited from a group above it, the way Epics already reaches up the tree with includeAncestors.

func (*Client) MyWork ¶

func (c *Client) MyWork(ctx context.Context, f forge.MyWorkFilter) ([]forge.WorkItem, error)

MyWork lists the current user's issues and merge requests across every project they can see.

GitLab has no single "everything of mine" endpoint, so this runs one query per kind and role — up to five — and merges them.

They run at once, and are merged in the order they were *asked for* rather than the order they arrived. An item matching several roles keeps the first in priority order, and that has to be a property of the list rather than of which request happened to come back quickest.

func (*Client) Namespaces ¶

func (c *Client) Namespaces(ctx context.Context, parent string) ([]forge.Namespace, error)

Namespaces lists subgroups of parent, or top-level groups when parent is "".

func (*Client) Pipelines ¶

func (c *Client) Pipelines(ctx context.Context, ref forge.Ref, f forge.PipelineFilter) ([]forge.Pipeline, error)

Pipelines lists a project's CI runs, most recent first.

func (*Client) Rebase ¶

func (c *Client) Rebase(ctx context.Context, ref forge.Ref, mr int) error

Rebase brings a merge request up to date with its target branch through GitLab's API. gu never runs git locally, so this is the only rebase path.

func (*Client) Repos ¶

func (c *Client) Repos(ctx context.Context, namespace string) ([]forge.Repo, error)

Repos lists the projects directly inside a group.

Simple is on because toRepo reads six fields and the full representation is closer to sixty, most of them settings blocks and permission matrices no listing has ever drawn. On a group of eleven projects that is 65 KB against 9.5 KB, and a second against under half of one — paid on the explorer's most common screen, every time it opens.

func (*Client) RetryPipeline ¶

func (c *Client) RetryPipeline(ctx context.Context, ref forge.Ref, pipelineID int) error

RetryPipeline re-runs a pipeline's failed and canceled jobs.

func (*Client) SetFields ¶

func (c *Client) SetFields(ctx context.Context, ref forge.Ref, target string, patch forge.FieldPatch) error

SetFields applies a partial update to an issue or merge request.

Milestone and Assignees are names a person recognises; GitLab's REST API wants ids, so both are resolved against the scope's milestones/members before writing. A name that resolves to nothing is reported back rather than dropped — a patch that looks applied and silently is not is the exact bug this method exists to close.

Status and Epic have no REST field at all — the REST issues endpoint does not carry them — so on an issue they go through a separate GraphQL mutation after the REST write. Merge requests have neither widget, so a patch touching them there is simply not applied — the same "ignore what does not apply" contract GitHub gets for Status/Epic on every target.

func (*Client) Starred ¶

func (c *Client) Starred(ctx context.Context) ([]forge.Repo, error)

Starred lists the current user's starred projects.

func (*Client) Statuses ¶ added in v0.6.0

func (c *Client) Statuses(ctx context.Context, s forge.Scope) ([]forge.Status, error)

Statuses lists the work-item statuses a scope's issues can take, each tagged with the category (see statusCategory) internal/ui/board.go sorts the status lanes by — GitLab's own array order is the configured lifecycle, but position is always 0 on every status, so category plus array order is the only signal that survives an admin renaming one.

The status widget needs a recent GitLab: on an instance without it, the query errors and this answers with nothing and no error, same as workItems above — a board that groups by label instead is far better than one that fails to open. StatusesStrict is the propagating twin, for a caller — the status picker — that needs to tell that apart from a real failure.

func (*Client) StatusesStrict ¶ added in v0.6.0

func (c *Client) StatusesStrict(ctx context.Context, s forge.Scope) ([]forge.Status, error)

StatusesStrict is Statuses without the fail-quiet wrapping — see its own doc comment, and forge.Forge's, for why the picker needs this instead.

func (*Client) Threads ¶

func (c *Client) Threads(ctx context.Context, ref forge.Ref, target string) ([]forge.Thread, error)

Threads lists the discussions on an issue or merge request.

It uses the discussions endpoint rather than notes: notes arrive as a flat list, and the reply structure of a review conversation is the whole point of showing them.

Every page is followed. A long-running merge request goes past a hundred discussions easily, and stopping at the first page did not lose the last comments visibly — it lost them silently, which is worse: the page looked complete and was short by a quarter.

func (*Client) Tree ¶

func (c *Client) Tree(ctx context.Context, ref forge.Ref, path, rev string) ([]forge.TreeEntry, error)

Tree lists the entries directly under a path.

func (*Client) Whoami ¶

func (c *Client) Whoami(ctx context.Context) (forge.User, error)

Whoami identifies the authenticated user.