Struct GitLabAdapter 

pub struct GitLabAdapter { /* private fields */ }

The glab adapter. Spawns glab issue <create|update|close|list> with the configured project and, when a secret is configured, the GITLAB_TOKEN env pair.

Implementations

impl GitLabAdapter

pub fn new( runner: impl CommandRunner + 'static, token: Option<String>, base_url: Option<String>, project: String, ) -> Self

Trait Implementations

impl TrackerAdapter for GitLabAdapter

fn set_relations( &mut self, remote_ref: &str, relations: &[MappedRelation], ) -> Result<()>

glab issue update <ref> --blocking <refs> (WP07 T030).

The only relation affordance glab exposes on an issue update is --blocking, so a blocks edge is the only thing that can leave the machine — and that is decided by the shared seam, not here. What arrives is already filtered; this method only renders it.

--blocking is not additive in glab: it replaces the issue’s blocked-by set. So the full set is sent in one call rather than one call per edge, which is also one fewer chance to leave the remote half-configured.

fn set_projects( &mut self, _remote_ref: &str, projects: &[MappedProject], ) -> Result<()>

GitLab’s side of the project-association seam — and its answer is “nothing” (WP08 T036).

glab names the one project an issue lives in (--project <path>, which this adapter already passes on every call) and exposes no membership flag, so there is no command line a membership list could be rendered as. Inventing one is precisely what T036 step 3 forbids, and sending a partial list would drop the rest of it, which C-005 forbids.

So this returns without spawning anything, and the debug_assert states the invariant the seam holds it to: the table that decides representability (PROJECT_WIRE_VERIFIED) is empty, so a value cannot reach here — and flipping that table without an implementation here would be a silent drop, which is loud in every test build instead.

fn set_epics(&mut self, _remote_ref: &str, epics: &[MappedEpic]) -> Result<()>

GitLab’s side of the epic-reference seam — and its answer is “nothing” (WP08, mission epics-work-items-01M3BYW4).

glab’s issue carries at most one epic (epic_iid, which this adapter already reads as the issue’s single parent) and exposes no flag to set it and no list form, so there is no command line an epic membership list could be rendered as. Inventing one is precisely what T038 step 3 forbids, and sending one member of a list would drop the rest, which C-007 forbids.

So this returns without spawning anything, and the debug_assert states the invariant the seam holds it to: the table that decides representability (EPIC_WIRE_VERIFIED) is empty, so a value cannot reach here — and flipping that table without an implementation here would be a silent drop, which is loud in every test build instead.

fn tool(&self) -> Tool

fn create_issue( &mut self, title: &str, body: &str, labels: &[String], assignee: Option<&str>, _priority: Option<&str>, _status: &str, ) -> Result<String>

Create a remote issue and return its remote id (GitLab iid, Linear identifier).

fn update_issue( &mut self, remote_ref: &str, title: &str, body: &str, labels: &[String], assignee: Option<&str>, _priority: Option<&str>, _status: &str, ) -> Result<()>

Update an existing remote issue in place.

fn mark_done(&mut self, remote_ref: &str) -> Result<()>

Convey “done” (GitLab: issue close <id>). Only invoked when done_via_status is false.

fn list_open(&mut self) -> Result<Vec<RemoteIssue>>

List open remote issues (the import source). Closed/done issues are excluded.

fn done_via_status(&self) -> bool

Linear sets done through the status flag; GitLab needs a separate close call.