Summary
Add gitlab_issues and gitlab_merge_requests as workflow trigger source types, following the existing patterns established by GitHub (gh CLI) and Linear (direct HTTP API). Also add assignee/assignees filtering to both GitLab and GitHub triggers.
Context
The orchestrator scheduler has a clean TaskSource trait + TriggerConfig tagged enum architecture supporting GitHub issues/PRs and Linear issues. GitLab needs equivalent support using the GitLab REST API v4, which allows both gitlab.com and self-hosted instances.
From #1178, the issue description notes that assignee was added to the issues trigger and assignees to the merge requests as an optional field, and the author has been meaning to add this to GitHub as well.
Architecture Decision: Direct HTTP API (not glab CLI)
Use the GitLab REST API v4 directly (like Linear) rather than the glab CLI (like GitHub) because:
glab CLI is far less commonly installed than gh
- Direct API supports self-hosted GitLab via configurable base URL
- GitLab REST API is straightforward - no GraphQL needed
- Follows the Linear integration pattern already in the codebase
Configuration Pattern
Following LinearConfig:
AGENTD_GITLAB_TOKEN env var (primary)
[gitlab] section in ~/.config/agentd/config.toml (fallback)
AGENTD_GITLAB_URL env var for self-hosted (default: https://gitlab.com)
YAML Template Format
# GitLab Issues
source:
type: gitlab_issues
owner: myorg
repo: myrepo
labels: [agent]
assignee: user
state: opened
# GitLab Merge Requests
source:
type: gitlab_merge_requests
owner: myorg
repo: myrepo
assignees: [user]
state: opened
Key Files
crates/orchestrator/src/scheduler/gitlab.rs (NEW)
crates/orchestrator/src/scheduler/types.rs - TriggerConfig variants
crates/orchestrator/src/scheduler/runner.rs - create_source() factory
crates/orchestrator/src/scheduler/api.rs - validation
crates/orchestrator/src/scheduler/template.rs - known variables
crates/orchestrator/src/scheduler/mod.rs - module registration
crates/cli/src/commands/apply.rs - SourceTemplate variants
schemas/workflow.yml - schema definitions
docs/public/trigger-reference.md - documentation
Child Issues
Related Issues
Stack Base
Stack on: feature/autonomous-pipeline
Summary
Add
gitlab_issuesandgitlab_merge_requestsas workflow trigger source types, following the existing patterns established by GitHub (ghCLI) and Linear (direct HTTP API). Also addassignee/assigneesfiltering to both GitLab and GitHub triggers.Context
The orchestrator scheduler has a clean
TaskSourcetrait +TriggerConfigtagged enum architecture supporting GitHub issues/PRs and Linear issues. GitLab needs equivalent support using the GitLab REST API v4, which allows both gitlab.com and self-hosted instances.From #1178, the issue description notes that assignee was added to the issues trigger and assignees to the merge requests as an optional field, and the author has been meaning to add this to GitHub as well.
Architecture Decision: Direct HTTP API (not glab CLI)
Use the GitLab REST API v4 directly (like Linear) rather than the
glabCLI (like GitHub) because:glabCLI is far less commonly installed thanghConfiguration Pattern
Following
LinearConfig:AGENTD_GITLAB_TOKENenv var (primary)[gitlab]section in~/.config/agentd/config.toml(fallback)AGENTD_GITLAB_URLenv var for self-hosted (default:https://gitlab.com)YAML Template Format
Key Files
crates/orchestrator/src/scheduler/gitlab.rs(NEW)crates/orchestrator/src/scheduler/types.rs- TriggerConfig variantscrates/orchestrator/src/scheduler/runner.rs- create_source() factorycrates/orchestrator/src/scheduler/api.rs- validationcrates/orchestrator/src/scheduler/template.rs- known variablescrates/orchestrator/src/scheduler/mod.rs- module registrationcrates/cli/src/commands/apply.rs- SourceTemplate variantsschemas/workflow.yml- schema definitionsdocs/public/trigger-reference.md- documentationChild Issues
GitlabIssueSourcetask sourceGitlabMergeRequestSourcetask sourceassignee/assigneesfilter fields to GitHub triggersRelated Issues
Stack Base
Stack on:
feature/autonomous-pipeline