gitlab-devops

name	gitlab-devops
description	GitLab DevOps operations — issues, merge requests, CI/CD pipelines, repository browsing, labels, milestones, releases, and wiki management. Use when querying GitLab project status, monitoring pipeline executions, browsing repository files, creating issues for network findings, opening merge requests for config changes, or managing project metadata.
version	1.0.0
license	Apache-2.0
tags	["gitlab","devops","ci-cd","version-control","change-management"]
metadata	{"openclaw":{"requires":{"bins":"[Truncated]","env":"[Truncated]"}}}

GitLab DevOps Skill

Golden Rule

Never execute write operations (create, update, delete, merge) without explicit operator confirmation. All mutating actions — creating issues, merging MRs, triggering pipelines, deleting labels — require human-in-the-loop approval before invocation (Constitution XIV). Always observe current state before making changes (Constitution II: Read-Before-Write).

MCP Server

This skill uses tools provided by the gitlab-mcp server (@zereight/mcp-gitlab), a community MCP server with 98+ tools for GitLab operations. The server is spawned locally via npx -y @zereight/mcp-gitlab and communicates over stdio transport.

Environment Variables

Variable	Required	Description
GITLAB_PERSONAL_ACCESS_TOKEN	Yes	GitLab PAT with api or read_api scope
GITLAB_API_URL	No	GitLab API URL (default: https://gitlab.com)
GITLAB_READ_ONLY_MODE	No	Restrict to read-only tools (default: false)

---

Workflow 1: Query Issues and Merge Requests (P1 — MVP)

Use this workflow to search, list, and inspect GitLab issues and merge requests for network project tracking.

Step 1: Discover Projects

Find the target project by name or keyword:

Tool: search_projects
Parameters: { "query": "network-automation" }

Or list all accessible projects:

Tool: list_projects
Parameters: { "per_page": 20 }

Step 2: List Issues

Query issues with filters for state, labels, assignee, or milestone:

Tool: list_issues
Parameters: {
  "project_id": "network-team/network-automation",
  "state": "opened",
  "labels": "outage",
  "assignee_username": "jcapobianco"
}

Step 3: Get Issue Details

Retrieve full details for a specific issue:

Tool: get_issue
Parameters: {
  "project_id": "network-team/network-automation",
  "issue_iid": 42
}

Step 4: View Issue Comments

List the discussion thread on an issue:

Tool: list_issue_comments
Parameters: {
  "project_id": "network-team/network-automation",
  "issue_iid": 42
}

Step 5: List Merge Requests

Query merge requests with filters:

Tool: list_merge_requests
Parameters: {
  "project_id": "network-team/infra-configs",
  "state": "opened",
  "labels": "needs-review"
}

Step 6: Get Merge Request Details

Retrieve MR details including diff stats and approval status:

Tool: get_merge_request
Parameters: {
  "project_id": "network-team/infra-configs",
  "merge_request_iid": 15
}

Example Prompts

• "Show me open issues in project network-automation"
• "List merge requests awaiting review in project infra-configs"
• "Get details for issue #42 in network-automation"
• "Show my assigned issues across all projects"
• "Find all projects matching 'network'"

---

Workflow 2: Monitor CI/CD Pipelines (P2)

Use this workflow to monitor pipeline status, inspect job details, and troubleshoot failures.

Step 1: List Pipelines

View pipeline executions for a project:

Tool: list_pipelines
Parameters: {
  "project_id": "network-team/network-configs",
  "status": "failed",
  "ref": "main"
}

Step 2: Get Pipeline Details

Retrieve details for a specific pipeline:

Tool: get_pipeline
Parameters: {
  "project_id": "network-team/network-configs",
  "pipeline_id": 123
}

Step 3: List Pipeline Jobs

Inspect jobs within a pipeline:

Tool: get_pipeline_jobs
Parameters: {
  "project_id": "network-team/network-configs",
  "pipeline_id": 123
}

Step 4: Get Job Log

Retrieve console output for troubleshooting:

Tool: get_pipeline_job_log
Parameters: {
  "project_id": "network-team/network-configs",
  "job_id": 456
}

Pipeline Control (Write Operations)

Requires operator confirmation. Skipped in read-only mode.

Trigger a New Pipeline

1. Verify the target branch exists and check current pipeline state
2. Present the action to the operator for confirmation
3. Trigger the pipeline:

Tool: create_pipeline
Parameters: {
  "project_id": "network-team/network-configs",
  "ref": "feature/bgp-tuning"
}

Retry a Failed Pipeline

1. Check the pipeline status to confirm it is in a failed state
2. Confirm with operator
3. Retry:

Tool: retry_pipeline
Parameters: {
  "project_id": "network-team/network-configs",
  "pipeline_id": 123
}

Cancel a Running Pipeline

1. Verify the pipeline is currently running
2. Confirm with operator
3. Cancel:

Tool: cancel_pipeline
Parameters: {
  "project_id": "network-team/network-configs",
  "pipeline_id": 124
}

Example Prompts

• "Show pipelines for project network-configs"
• "Show failed pipelines on the main branch"
• "Get the job log for pipeline #123"
• "Retry the failed pipeline for network-configs"
• "Cancel the running pipeline #124"

---

Workflow 3: Browse Repositories and Files (P3)

Use this workflow to inspect repository structure, read file contents, and review change history.

Step 1: List Repository Tree

View the directory structure:

Tool: list_repository_tree
Parameters: {
  "project_id": "network-team/network-configs",
  "path": "ansible/",
  "ref": "main"
}

Step 2: Get File Content

Read a specific file:

Tool: get_file_content
Parameters: {
  "project_id": "network-team/network-configs",
  "file_path": "ansible/site.yml",
  "ref": "main"
}

Step 3: List Commits

View commit history with filters:

Tool: list_commits
Parameters: {
  "project_id": "network-team/network-configs",
  "ref_name": "main",
  "path": "ansible/",
  "since": "2026-03-01T00:00:00Z"
}

Step 4: Get Commit Details

Inspect a specific commit with diff:

Tool: get_commit
Parameters: {
  "project_id": "network-team/network-configs",
  "sha": "abc123def"
}

Step 5: Compare Branches

Review differences between branches:

Tool: compare_branches
Parameters: {
  "project_id": "network-team/network-configs",
  "from": "main",
  "to": "feature/bgp-tuning"
}

Example Prompts

• "Show the directory structure of project network-configs"
• "Show me the contents of ansible/site.yml on the develop branch"
• "List recent commits on the main branch for the ansible/ directory"
• "Compare the main and feature/bgp-tuning branches"
• "Show the diff for commit abc123def"

---

Workflow 4: Manage Issues and Merge Requests (P4)

All write operations require operator confirmation. Skipped in read-only mode.

Issue Management

Create an Issue

1. Verify the target project exists via get_project
2. Present the issue details to the operator for confirmation
3. Create the issue:

Tool: create_issue
Parameters: {
  "project_id": "network-team/network-automation",
  "title": "BGP peer flapping on router-01",
  "description": "Router-01 BGP peer to router-02 (192.168.1.1) is flapping every 30 seconds. Hold timer expiry detected. Investigate and resolve.",
  "labels": "outage,bgp,priority::critical",
  "assignee_ids": [42]
}

Update an Issue

1. Read current issue state via get_issue
2. Present proposed changes to operator
3. Update:

Tool: update_issue
Parameters: {
  "project_id": "network-team/network-automation",
  "issue_iid": 42,
  "state_event": "close",
  "labels": "outage,bgp,resolved"
}

Add a Comment

Tool: add_issue_comment
Parameters: {
  "project_id": "network-team/network-automation",
  "issue_iid": 42,
  "body": "Root cause identified: BGP hold timer set to 10s, peer timer at 30s. Aligned timers to 90/30. Peering stable for 15 minutes."
}

Merge Request Management

Create a Merge Request

1. Verify source and target branches exist via compare_branches
2. Present MR details to operator for confirmation
3. Create the MR:

Tool: create_merge_request
Parameters: {
  "project_id": "network-team/infra-configs",
  "title": "fix: align BGP hold timers on router-01",
  "source_branch": "fix/bgp-timer-alignment",
  "target_branch": "main",
  "description": "Aligns BGP hold timer from 10s to 90s on router-01 peer to router-02.\n\nServiceNow CR: CHG0012345\nGAIT Session: gait-abc123"
}

Update a Merge Request

1. Read current MR state via get_merge_request
2. Present proposed changes to operator
3. Update:

Tool: update_merge_request
Parameters: {
  "project_id": "network-team/infra-configs",
  "merge_request_iid": 15,
  "labels": "approved,ready-to-merge"
}

Add a Comment to a Merge Request

Tool: add_merge_request_comment
Parameters: {
  "project_id": "network-team/infra-configs",
  "merge_request_iid": 15,
  "body": "Verified in CML lab. BGP peering stable after timer change. Ready to merge."
}

Merge a Merge Request

1. Verify MR has no conflicts and approvals are met via get_merge_request
2. Explicitly confirm with operator — this is irreversible
3. Merge:

Tool: merge_merge_request
Parameters: {
  "project_id": "network-team/infra-configs",
  "merge_request_iid": 15,
  "squash": true,
  "should_remove_source_branch": true
}

Example Prompts

• "Create an issue in project network-automation titled 'BGP peer flapping on router-01'"
• "Close issue #42 in network-automation"
• "Create a merge request from fix/bgp-timer-alignment to main in infra-configs"
• "Merge MR #15 in infra-configs with squash"
• "Add a comment to MR #15: 'Verified in lab, ready to merge'"

---

Workflow 5: Manage Labels, Milestones, Releases, and Wiki (P5)

Label Management

Tool: list_labels
Parameters: { "project_id": "network-team/network-automation" }

Tool: create_label  (requires confirmation, skipped in read-only mode)
Parameters: {
  "project_id": "network-team/network-automation",
  "name": "critical-infrastructure",
  "color": "#FF0000"
}

Milestone Management

Tool: list_milestones
Parameters: { "project_id": "network-team/network-automation" }

Tool: create_milestone  (requires confirmation, skipped in read-only mode)
Parameters: {
  "project_id": "network-team/network-automation",
  "title": "Q2 2026 Network Refresh",
  "due_date": "2026-06-30"
}

Release Management

Tool: list_releases
Parameters: { "project_id": "network-team/network-configs" }

Tool: get_release
Parameters: {
  "project_id": "network-team/network-configs",
  "tag_name": "v2.1.0"
}

Tool: create_release  (requires confirmation, skipped in read-only mode)
Parameters: {
  "project_id": "network-team/network-configs",
  "tag_name": "v2.2.0",
  "name": "Network Configs v2.2.0",
  "description": "BGP timer alignment and OSPF area optimization"
}

Wiki Page Management

Tool: list_wiki_pages
Parameters: { "project_id": "network-team/network-automation" }

Tool: get_wiki_page
Parameters: {
  "project_id": "network-team/network-automation",
  "slug": "bgp-runbook"
}

Tool: create_wiki_page  (requires confirmation, skipped in read-only mode)
Parameters: {
  "project_id": "network-team/network-automation",
  "title": "Incident Postmortem: Router-01 BGP Flap",
  "content": "## Summary\n\nBGP peering between router-01 and router-02 was flapping..."
}

Example Prompts

• "List milestones for project network-automation"
• "Create a label called 'critical-infrastructure' with red color"
• "Show releases for project network-configs"
• "Show the BGP runbook wiki page in network-automation"
• "Create a wiki page for the router-01 incident postmortem"

---

GAIT Audit Logging

All GitLab interactions MUST be logged to the GAIT audit trail via gait_mcp tools at skill invocation level.

Logging Pattern

For each operation, log:

1. Before: Tool name, parameters (excluding tokens), and operator intent
2. After: Result summary (issue key created, pipeline status, etc.)

Tool: gait_log
Parameters: {
  "action": "gitlab.list_issues",
  "details": "Queried open issues in network-automation with label 'outage'",
  "result": "Returned 7 open issues"
}

For write operations, include the confirmation step:

Tool: gait_log
Parameters: {
  "action": "gitlab.create_issue",
  "details": "Created issue 'BGP peer flapping on router-01' in network-automation. Operator confirmed.",
  "result": "Issue #43 created at https://gitlab.com/network-team/network-automation/-/issues/43"
}

---

Read-Only Mode

When GITLAB_READ_ONLY_MODE=true, the skill restricts to observation-only operations:

Allowed tools (read-only):

• list_issues, get_issue, list_issue_comments
• list_merge_requests, get_merge_request
• list_pipelines, get_pipeline, get_pipeline_jobs, get_pipeline_job_log
• list_repository_tree, get_file_content, list_commits, get_commit, compare_branches
• list_projects, get_project, search_projects
• list_labels, list_milestones, list_releases, get_release
• list_wiki_pages, get_wiki_page

Blocked tools (write operations — skipped with message):

• create_issue, update_issue, add_issue_comment
• create_merge_request, update_merge_request, merge_merge_request, add_merge_request_comment
• create_pipeline, retry_pipeline, cancel_pipeline
• create_label, update_label, delete_label
• create_milestone, update_milestone
• create_release
• create_wiki_page, update_wiki_page, delete_wiki_page

When a write tool is requested in read-only mode, respond: "GitLab read-only mode is enabled (GITLAB_READ_ONLY_MODE=true). Write operations are disabled. Contact your administrator to enable write access."

---

Integration with Other Skills

• servicenow-change-workflow — Reference ServiceNow CR numbers in MR descriptions and issue comments for ITSM traceability
• gait-session-tracking — All GitLab operations are logged to the GAIT audit trail
• github-ops — Similar workflows for GitHub-hosted repositories; use gitlab-devops for GitLab and github-ops for GitHub
• canvas-network-viz — Visualize pipeline status and project metrics in the Canvas/A2UI dashboard

Important Rules

• Never expose personal access tokens in logs, comments, or error messages
• Always verify project existence before write operations
• Reference ServiceNow CR numbers in MR descriptions when applicable
• Log all operations to GAIT for audit compliance
• In read-only mode, gracefully skip write operations with a clear message
• For self-hosted GitLab with nested groups, use full path (e.g., "org/team/sub-team/project")