CI/CD Workflow Examples
These step-by-step CI/CD workflows show how to diagnose pipeline failures, manage CI/CD variables, schedule builds, control environments, validate config, and read DORA metrics — all in natural language. Each example pairs the prompt you type with the exact meta-tool action the server runs, so you can see precisely what happens behind the scenes and reuse the call directly.
Diagnose a failing pipeline
Section titled “Diagnose a failing pipeline”When a pipeline fails, this workflow takes you from the list of failed pipelines down to the specific job log that explains the failure — without leaving your assistant. List failed pipelines, drill into the failing jobs, then read the job log to find the root cause.
sequenceDiagram
participant U as User
participant AI as AI Assistant
participant MCP as MCP Server
participant GL as GitLab API
U->>AI: "Show me failed pipelines"
AI->>MCP: gitlab_pipeline (action: list)
MCP->>GL: GET /projects/:id/pipelines
GL-->>MCP: Pipeline list
MCP-->>AI: Failed pipelines
AI->>U: "Found 2 failed pipelines"
U->>AI: "Show failed jobs in #45892"
AI->>MCP: gitlab_pipeline (action: job_list)
MCP->>GL: GET /projects/:id/pipelines/:id/jobs
GL-->>MCP: Job details
MCP-->>AI: Failed jobs
AI->>MCP: gitlab_pipeline (action: job_log)
MCP->>GL: GET /projects/:id/jobs/:id/trace
GL-->>MCP: Log output
MCP-->>AI: Job logs
AI->>U: Root cause analysis + fix
Get pipeline overview
Section titled “Get pipeline overview”Prompt: “Show me all failed pipelines in my-group/backend”
gitlab_pipeline → action: list, project_id: "my-group/backend", status: "failed"Returns: pipeline IDs, branches, failure reasons, and durations.
Drill into a failed pipeline
Section titled “Drill into a failed pipeline”Prompt: “Show me the failed jobs in pipeline #45892”
gitlab_pipeline → action: job_list, project_id: "my-group/backend", pipeline_id: 45892, scope: "failed"Returns: job names, stages, failure messages, and runner info.
Read job logs
Section titled “Read job logs”Prompt: “Get the log output from the ‘test-integration’ job in pipeline #45892”
gitlab_pipeline → action: job_log, project_id: "my-group/backend", job_id: 98765Returns: full job log output. Useful for diagnosing test failures without opening the GitLab UI.
Manage CI/CD variables
Section titled “Manage CI/CD variables”Configure the environment your pipelines run in by listing, creating, and scoping CI/CD variables. Use this to inspect what is already set, add secrets like deploy tokens with masking and protection, or restrict a variable to a single environment.
List project variables
Section titled “List project variables”Prompt: “What CI/CD variables are configured in the backend project?”
gitlab_ci_variable → action: project_list, project_id: "my-group/backend"Returns: variable keys, protection status, masking status, and environment scopes. Values are masked for security.
Add a deployment variable
Section titled “Add a deployment variable”Prompt: “Add a CI/CD variable DEPLOY_TOKEN with value ‘abc123’ to the backend project, masked and protected”
gitlab_ci_variable → action: project_create, project_id: "my-group/backend", key: "DEPLOY_TOKEN", value: "abc123", masked: true, protected: trueUpdate variable scope
Section titled “Update variable scope”Prompt: “Update the DATABASE_URL variable in backend to only apply to the production environment”
gitlab_ci_variable → action: project_update, project_id: "my-group/backend", key: "DATABASE_URL", environment_scope: "production"Pipeline schedules
Section titled “Pipeline schedules”Automate recurring pipelines with cron-based schedules — for example a nightly build — and review which schedules already exist and when they run next.
Create a nightly build
Section titled “Create a nightly build”Prompt: “Create a pipeline schedule that runs every night at 2 AM UTC on the main branch”
gitlab_pipeline → action: schedule_create, project_id: "my-group/backend", description: "Nightly build", ref: "main", cron: "0 2 * * *", cron_timezone: "UTC"List active schedules
Section titled “List active schedules”Prompt: “Show me all pipeline schedules in the backend project”
gitlab_pipeline → action: schedule_list, project_id: "my-group/backend"Returns: schedule descriptions, cron expressions, next run times, and owner info.
Environment management
Section titled “Environment management”Track and control where your code is deployed. List environments to see their state and URLs, review deployment history for production, and stop ephemeral review environments when they are no longer needed.
List environments
Section titled “List environments”Prompt: “Show me all environments for the backend project”
gitlab_environment → action: list, project_id: "my-group/backend"Returns: environment names, external URLs, last deployment info, and state.
Check deployment history
Section titled “Check deployment history”Prompt: “Show recent deployments to the production environment”
gitlab_environment → action: deployment_list, project_id: "my-group/backend", environment: "production"Stop a review environment
Section titled “Stop a review environment”Prompt: “Stop the review/feature-login environment in the backend project”
gitlab_environment → action: stop, project_id: "my-group/backend", environment_id: 42Validate CI configuration
Section titled “Validate CI configuration”Catch .gitlab-ci.yml mistakes before they break a pipeline by linting the config. The server returns the validation status alongside the fully merged YAML, so you can confirm that includes and templates resolve as expected.
Lint CI config
Section titled “Lint CI config”Prompt: “Validate the .gitlab-ci.yml in my-group/backend for syntax errors”
gitlab_template → action: ci_lint, project_id: "my-group/backend"Returns: validation status, merged YAML, warnings, and error details.
DORA metrics
Section titled “DORA metrics”Measure delivery performance with the four DORA metrics — deployment frequency, lead time for changes, time to restore service, and change failure rate — at either project or group scope. DORA metrics require a GitLab Premium or Ultimate license.
Project performance
Section titled “Project performance”Prompt: “Show me DORA metrics for the backend project over the last 30 days”
gitlab_dora_metrics → action: project, project_id: "my-group/backend", metric: "all", start_date: "2024-01-01", end_date: "2024-01-31"Returns: deployment frequency, lead time for changes, time to restore service, and change failure rate.
Group-level metrics
Section titled “Group-level metrics”Prompt: “Compare DORA metrics across all projects in the platform group”
gitlab_dora_metrics → action: group, group_id: "platform", metric: "all", interval: "monthly"Returns: aggregated metrics for the entire group, useful for engineering leadership dashboards.
Dynamic-first CI/CD calls
Section titled “Dynamic-first CI/CD calls”In the default dynamic surface, the assistant discovers the exact CI/CD action and its schema first, then executes it — so the prompts above resolve to canonical domain.action IDs rather than named meta-tools. The two-step pattern is find, then execute:
gitlab_find_action → query: "latest pipeline status for project"gitlab_execute_action → action: "pipeline.latest", params: { project_id: "42" }For failed jobs, discover the log or retry action first, then execute with the returned schema:
gitlab_find_action → query: "get failed job trace"gitlab_execute_action → action: "job.trace", params: { project_id: "42", job_id: 9876 }