gitlab·May 7, 2026·3 min readCurated summary

Automate deployment processes with GitLab Duo Agent Platform

GitLab Duo Agent Platform can automate the complex, repetitive work of onboarding a microservice into an established GitOps workflow. By analyzing an application’s repositories and configuration, a custom agent can generate manifests, update pipelines, configure image automation, and follow organization-specific conventions. The approach combines AI-driven speed with GitLab-managed versioning, governance, and enterprise security. ## TanukiBank’s GitOps Use Case - The fictional TanukiBank application needs a new `intra-account-transfers` microservice for its Quick Transfer feature. - Its deployment architecture includes: - Individual service projects with container registries and build pipelines. - **Tanuki Bank - Delivery**, which stores deployment manifests and delivery pipelines. - **Flux Config**, which contains Flux manifests for Kubernetes. - Flux Image Automation watches service registries and updates corresponding delivery manifests. - A delivery pipeline then builds and signs the image, while Flux CD synchronizes it to the Kubernetes cluster. - Adding a service manually requires coordinated changes across all these components. ## Generating the Custom Agent’s System Prompt - GitLab Duo Agentic Chat examines the TanukiBank group, subgroups, source files, Dockerfiles, manifests, configuration, and dependencies. - It generates a detailed system prompt describing: - The existing GitOps workflow. - Required operating rules. - Reporting instructions. - Recommended tools. - The prompt is specific to the workflow at the time it is generated. - If the application’s GitOps process changes, the prompt should be regenerated. ## Creating and Configuring the Agent - A new `application-agents` project manages custom agents, their administrators, and where they can run. - A managed agent named **TanukiBank Microservice Onboarder** is created with: - A description. - The generated system prompt. - Tools recommended by GitLab Duo. - The agent is enabled in both **Tanuki Bank - Delivery** and **Flux Config**. - Its presence in each project’s Agentic Chat agent selector confirms that it is available. ## Creating the Microservice - A new `services/intra-account-transfers` project is created. - GitLab Duo’s **Developer** foundational flow implements the service from an issue specification. - The flow: - Reads the requirements. - Writes the implementation. - Creates a branch and merge request. - Links the merge request to the issue. - After local verification with `curl`, the merge request is merged and the project pipeline publishes container images. - At this stage, the service exists, but the GitOps system has not been updated: - `manifests/dev` has no service manifests. - The delivery pipeline does not reference the service. - `Flux Config` lacks an `image-update-automation.yaml` entry. ## Using the Custom Onboarding Agent - The custom agent is enabled in the new service project. - From **Tanuki Bank - Delivery**, the user selects **TanukiBank Microservice Onboarder** in Agentic Chat and provides the service name and hostname. - The agent begins onboarding by: - Finding and reading the service’s Dockerfile. - Determining the application port. - Generating the required Kubernetes manifests. - Updating the relevant delivery pipelines. - This automates the coordinated repository changes normally required for a new microservice. ## Practical Takeaway A custom GitLab Duo agent is most valuable when it is grounded in an organization’s real repositories and deployment conventions. Generate its prompt from the current system, keep the agent centrally governed, and regenerate the prompt whenever the GitOps workflow changes.

Read original(opens in new tab)

KubernetesCI/CDDocker & ContainersMicroservices+3

gitlab·May 7, 2026·2 min readCurated summary

A leaked personal access token shouldn't expose every project its owner can reach. Fine-grained PATs scope each token’s permissions to the job.

Fine-grained personal access tokens (PATs) reduce credential exposure by limiting each token to only the projects, groups, resources, and actions required for a specific task. GitLab’s beta lets users replace broad `api` or `read_api` tokens with narrowly scoped permissions, reducing the impact of leaks. The feature is not yet recommended for production because coverage is still incomplete. ## Why Narrow PAT Privileges - Broad, user-scoped tokens can access every project the user can reach. - A leaked token might expose source code, pipelines, container images, or CI/CD variables across many projects. - Fine-grained tokens limit both access and potential remediation to the affected project or resource. - They complement lifetime limits and automatic revocation. ## How Fine-Grained Tokens Work - Scope access by location: - Personal projects - All projects and groups where the user is a member - Specifically selected projects and groups - Assign independent Create, Read, Update, and Delete permissions. - Supported resources include Issues, Merge Requests, Pipelines, Repositories, and Container Registry. - Example: a container-publishing pipeline can receive Create and Read access only to one project’s registry. ## Auditing and Beta Coverage - The token management table displays scopes and per-resource permissions for all tokens. - This makes over-privileged credentials easier to identify during reviews. - Fine-grained PATs currently support about 75% of REST API endpoints. - GitLab plans to add remaining REST endpoints and expand GraphQL support. - Existing traditional PATs continue working alongside fine-grained tokens during the beta. ## Getting Started - Go to **User Settings → Personal Access Tokens**. - Select **Fine-grained token** when generating a token. - Choose the permitted projects or groups and assign resource permissions. - GitLab recommends avoiding fine-grained PATs in production until general availability. Teams should begin evaluating fine-grained tokens for automation and adopt one token per job, with the smallest practical scope. Feedback during the beta will help shape broader endpoint coverage and future improvements.

Read original(opens in new tab)

GitlabGraphQLRest ApiApi Security+3

gitlab·May 6, 2026·3 min readCurated summary

Claude Code and GitLab: Three workflows that ship

Claude Code accelerates coding, but writing code is only one part of shipping software. The post argues that GitLab complements Claude Code by handling CI/CD, security scanning, code review, approvals, and auditability. It presents three workflows: fixing bugs locally, enriching Claude with GitLab context through MCP, and using a Claude-powered external agent to resolve merge request feedback. ## The Gap Between Coding and Shipping - Agentic tools can quickly understand unfamiliar code, propose fixes, and scaffold features. - Faster code generation can leave teams with: - Larger bug backlogs - More pipeline failures - Accumulating security vulnerabilities - Bottlenecks in review and approval - GitLab manages the downstream software lifecycle after Claude Code produces a change. ## Prerequisites and Project Setup - Claude Code must be installed and configured. - A GitLab project containing bug reports and feature proposals is required, such as the Tanuki IoT Platform. - Optional workflows require: - The GitLab MCP Server - GitLab Duo Agent Platform with external agents - The example project uses CMake, Make, and GCC or Clang for C++ builds. - Developers clone the repository, launch `claude`, and can ask it to explain the project before making changes. ## Workflow One: Fix a C++ Bug and Ship It Through GitLab - The Arduino IoT Collector crashes when `/dev/ttyACM0` is unavailable. - The failure can be reproduced by building and running the application with CMake: - `cmake -S . -B build` - `cmake --build build` - `./build/arduino_iot_collector` - Claude Code examines `sensors/arduino-iot-collector/src/main.cpp` and identifies an uncaught `std::runtime_error`. - The recommended behavior is to log a clear configuration error and continue running instead of terminating. - After the fix, Claude Code can create a branch, commit the changes, and push them, or the developer can run the Git commands manually. - Opening a merge request triggers: - Build and test pipelines - Security scanning - GitLab Duo Code Review Flow - Checks against project style guides and custom review instructions ## Workflow Two: Add GitLab Context with MCP - Local repository files may not contain the full history behind a bug. - GitLab issues, debugging discussions, previous merge requests, and related fixes provide valuable software development lifecycle context. - The GitLab MCP Server connects Claude Code to this information. - It can be added over HTTP with a command such as: `claude mcp add --transport http GitLab https://gitlab.example.com/api/v4/mcp` - In a new Claude Code session, `/mcp` starts OAuth authentication through the browser. - Developers can verify the integration by asking Claude which GitLab MCP tools and server version are available. - MCP uses the developer’s existing GitLab identity: - It does not grant elevated permissions. - Claude can access only projects, issues, merge requests, and other data already visible to that user. ## Workflow Three: Resolve Review Feedback with an External Agent - The third workflow uses a Claude-powered external agent in GitLab Duo Agent Platform. - Rather than requiring a developer to manually interpret review comments, the agent can address code review feedback directly in the merge request. - This extends Claude Code’s implementation abilities into GitLab’s review and delivery workflow. ## Overall Recommendation Use Claude Code for investigation and implementation, then use GitLab to provide the context, automated validation, security checks, review, and approval process needed to ship those changes safely.

Read original(opens in new tab)

GitlabCode ReviewClaude CodeC Plus Plus+4

gitlab·May 5, 2026·3 min readCurated summary

8 Agentic AI patterns reshaping team collaboration

A synthesis of 17 agentic AI platforms identifies eight patterns that help teams work faster, work smarter, and maintain control. The strongest platforms do more than provide capable individual agents: they reduce coordination overhead, embed agents in existing workflows, and provide governance across the software lifecycle. The post argues that integrated team collaboration and managed deployment will distinguish leading AI platforms. ## Eight Collaboration Patterns ### Proactive Status Updates - Agents generate progress summaries from live task data. - They identify blockers, risks, and slipping deadlines before escalation. - Automated updates reduce status meetings and manual check-ins. ### Intelligent Work Routing - Agents assign work based on skills, capacity, and project context. - Continuous workload balancing replaces periodic planning adjustments. - Transparent routing logic lets humans review and correct assignments. ### Team Communication Support - Agents summarize chats, threads, and meetings. - Decisions and conversation history remain available to new participants. - Async summaries reduce repeated explanations and unnecessary meetings. ### Role-Specific Agents in Chat - Specialist agents operate inside tools such as Slack. - They can handle onboarding, IT, sales, and other role-based tasks. - Simple interactions, such as an emoji reaction, can create tracked work. ### Shared Conversational Context - Agents retain awareness of participants, threads, and files. - Teams benefit from knowledge gathered through another member’s prompt. - Shared context prevents duplicated prompting and helps new members continue work immediately. ### Role-Based Access Control - Agents inherit permissions from their assigned identities and roles. - Access controls can apply at the field level, preventing unauthorized reading or actions. - Detailed action logs provide an auditable record for compliance. ### Governed Environments - Agents move through development, testing, and production using managed pipelines. - Sandboxes isolate early development and prevent conflicts. - Controlled promotion prevents untested agents or disruptive updates from reaching production. ### Collaborative Agent Development - Multiple team members can co-own, edit, debug, and maintain agents. - Tiered permissions support shared ownership without removing accountability. - Standardized protocols help agents created by different contributors work together. ## Lessons from the Competitive Landscape - Agents are increasingly embedded in existing communication and work tools rather than isolated portals. - Governance becomes essential as organizations scale agent usage. - Agent development is evolving into a collaborative discipline requiring shared ownership, versioning, and auditing. - The biggest opportunity is reducing the “coordination tax” of meetings, check-ins, and repeated explanations. - Few platforms provide an end-to-end governance experience combining environment grouping, shared catalogs, and managed promotion pipelines. ## Implications for GitLab GitLab’s integrated DevSecOps lifecycle gives it a structural advantage because software delivery workflows, context, and controls already exist in one platform. GitLab Duo Agent Platform is positioned to embed agents directly into those workflows, allowing teams to orchestrate work while agents execute across the software development lifecycle. Teams evaluating agentic AI should prioritize not only agent capability, but also shared context, transparent automation, permissions, deployment governance, and collaborative maintenance.

Read original(opens in new tab)

AI AgentsGitlabDevSecOpsGovernance+3

gitlab·May 4, 2026·3 min readCurated summary

Atlassian will train on your data: Opt out with GitLab

Atlassian plans to use customer metadata and in-app content from Jira, Confluence, and other cloud products to train AI services beginning August 17, 2026. Collection will be enabled by default, with mandatory metadata collection for Free, Standard, and Premium customers; only Enterprise customers can opt out. The post argues this weakens data governance, particularly for regulated organizations, while presenting GitLab’s no-collection, no-training approach as a stronger privacy model. ## What Atlassian’s Policy Change Covers - Atlassian will collect: - Metadata such as story points, sprint dates, SLA values, and signals from Teamwork Graph and connected apps. - In-app content including Confluence pages, Jira issue titles, descriptions, and comments. - Atlassian says data will be de-identified and aggregated before training. - Data may be retained for up to seven years. - After opting out, in-app data is reportedly removed within 30 days and models retrained within 90 days. - Customers using customer-managed encryption keys, Government Cloud, Isolated Cloud, or HIPAA-related configurations are excluded. - The change reverses Atlassian’s previous position that customer data would not be used to train or improve AI services. ## Problems with Opt-Out-by-Default Governance - Customers must notice the policy change, assess its legal and security impact, and act within the available timeframe. - Free, Standard, and Premium customers cannot disable metadata collection. - Enterprise is the only opt-out route, requiring at least 801 users and custom pricing. - “De-identified” metadata can still reveal team performance, project structure, delivery cadence, and competitive operational intelligence. - The policy turns data protection into a purchasing decision rather than a default customer right. ## Why Atlassian Customers Face Greater Exposure - Jira and Confluence often contain: - Project plans and sprint data - Security tickets and incident postmortems - Internal documentation - Bug, release, and portfolio management information - Organizations using Bitbucket and Bamboo may also expose source-code metadata and CI/CD configuration signals. - Teamwork Graph connectors can extend the data scope to tools such as Slack, Figma, Google Drive, Salesforce, and ServiceNow. - Customers migrating from Data Center or Server editions to Atlassian Cloud must now evaluate not only cloud migration, but also the possibility of default AI training. ## Compliance and Regulatory Implications - Financial institutions may need to reassess vendor controls under frameworks such as SR 11-7 and DORA. - Public-sector organizations must consider NIST 800-53 and FISMA requirements around sensitive-data flows. - Healthcare organizations need to evaluate potential HIPAA implications. - EU AI Act obligations may create additional concerns because European expectations often favor opt-in consent. - Existing vendor-risk, model-risk, and data-processing assessments should be updated before August 17, 2026. ## GitLab’s Contrasting Approach - GitLab is presented as opposing opt-out-by-default collection. - Its stated principles are: - No collection of customer data - No AI training on customer data - The same privacy commitment regardless of subscription tier - This approach avoids making stronger data protection dependent on Enterprise pricing and simplifies compliance reviews. Organizations should inventory the data and integrations connected to Atlassian, review contractual and regulatory obligations, and determine whether they can opt out or need to reconsider their platform strategy.

Read original(opens in new tab)

GitlabCloud ComputingJiraData Privacy+3

gitlab·May 4, 2026·2 min readCurated summary

How to detect and prevent Contagious Interview IDE attacks

Contagious Interview attacks abuse VS Code’s automated tasks to execute malware when victims open a malicious repository and trust its workspace. GitLab developed low-level EDR detections around `node-pty`’s `spawn-helper`, allowing it to identify hidden background process execution while avoiding normal interactive developer activity. The article recommends combining runtime detection with IDE configuration hardening. ## The Contagious Interview Attack Path - North Korean threat actors use fake job interviews to persuade targets to download and review malicious code repositories. - Repositories can include a `.vscode/tasks.json` file configured to run automatically when the folder opens. - After the victim grants workspace trust, the task executes without obvious interaction. - Example payloads: - Detect the operating system. - Download a platform-specific second-stage payload. - Pipe it directly into `bash`, `sh`, or `cmd` using patterns such as `curl | bash`. - Resulting malware may steal passwords and cryptocurrency, deploy infostealers, and establish persistence for abuse of corporate access. ## Low-Level Detection with `spawn-helper` - GitLab looked below the VS Code layer because similar attacks can affect VS Code forks and other Node- or Electron-based IDEs. - VS Code uses the popular `node-pty` library to launch subprocesses. - `node-pty.spawn()` invokes a `spawn-helper` binary, which becomes a child process of the Node application. - This makes `spawn-helper` a useful operating-system-level signal for background task execution. ## Reducing False Positives - GitLab used Purple Team exercises to reproduce the attack and reviewed EDR telemetry. - Background VS Code tasks use `spawn-helper`, while foreground interactive processes such as the integrated terminal use a Code Helper binary. - Detections can therefore focus on processes launched invisibly, without user interaction. - GitLab further tuned alerts to identify suspicious commands such as background `curl | <shell>` execution rather than flagging every automated task. - The resulting detection produced no false positives despite widespread VS Code usage internally. ## Additional Prevention Measures - Runtime EDR monitoring is only one layer of defense. - Organizations can proactively harden their fleets by deploying global VS Code configuration that disables automatic task execution. - Combining IDE restrictions with process telemetry and behavioral detection provides broader protection against malicious repository-based attacks. Organizations should disable automatic task runs where practical and monitor low-level subprocess behavior, especially invisible `spawn-helper` executions that download or pipe remote content into a shell.

Read original(opens in new tab)

Node.JsElectronThreat IntelligenceVisual Studio Code+4

gitlab·Apr 30, 2026·3 min readCurated summary

Automate detection testing with GitLab CI/CD and Duo

GitLab’s WATCH framework continuously tests whether security detections still work in real conditions, rather than only verifying that detection rules deploy successfully. It runs simulated attacks in staging, checks alert propagation through logging, SIEM, and SOAR systems, and reports failures automatically. The framework uses GitLab CI/CD to schedule randomized tests, correlate expected alerts, and publish detection-health results. ## The Detection-Validation Gap - Security detections can silently fail because of: - Log schema changes - SIEM updates - Ingestion or pipeline misconfigurations - Other changes between the log source and alerting systems - Reinjecting synthetic logs into a SIEM can test rule logic, but it does not validate real-world behavior or the log-ingestion path. - GitLab’s detections-as-code pipelines confirm that rules can be created and deployed, but not that they fire when the targeted activity occurs. - WATCH fills this gap by validating detections end to end. ## WATCH’s Testing Lifecycle - **Scheduling:** A weekly GitLab CI/CD pipeline discovers active tests and assigns them randomized execution times. - **Heads-up notification:** WATCH creates a dedicated “WATCH Heads Up” SOAR record containing the detections expected to fire. - **Execution:** Scripts perform simulated malicious actions in staging, such as resetting an administrator password or making suspicious API calls. - **Detection:** Activity logs flow through ingestion into the SIEM, where detection rules process them. - **Correlation:** SOAR matches alerts to registered WATCH tests using: - The time window between execution and alerting - Actor identity, such as an IP address or username - The detection rule ID - **Verification:** A follow-up job confirms that all expected detections fired, updates detection metadata, and publishes results to a GitLab Pages dashboard. - Failed tests generate notifications in the team’s Slack channel. - Correlation prevents test alerts from being escalated as genuine incidents while still validating the complete alerting pipeline. ## GitLab CI/CD Implementation WATCH is organized into three pipeline stages: - **`schedule_pipelines`:** - Runs weekly. - Finds active tests and groups them into scheduled pipelines. - Passes the selected tests through the `TESTS_TO_RUN` variable. - **`run_tests`:** - Executes the assigned attack simulations. - Saves execution results in `detection_status.json`. - Records SOAR identifiers needed for later alert correlation. - **`pages`:** - Queries the SOAR to verify alert generation and routing. - Updates `detection_status.json` with test results. - Deploys the latest status data and dashboard assets to GitLab Pages. The example configuration uses Python 3.12, pipeline inputs to enable weekly scheduling or dashboard updates, conditional `rules`, and GitLab Pages artifacts. Scheduled execution is randomized to avoid predictable test patterns and to expose timing-related problems. ## Practical Recommendation Organizations with critical security detections should add continuous behavioral testing alongside detections-as-code validation. A framework like WATCH can provide earlier warning of broken ingestion, rules, or routing while reducing the cost and generic limitations of commercial breach-and-attack simulation tools.

Read original(opens in new tab)

Database DesignPythonSecurity MonitoringSiem+4

gitlab·Apr 29, 2026·2 min readCurated summary

Teaching software development the easy way using GitLab

GitLab for Education can turn the administrative work of teaching software development into a scalable, professional workflow. University of Washington lecturer Stephen G. Dame uses GitLab groups, controlled permissions, merge requests, and inline comments to distribute materials, protect solutions, and provide contextual feedback. The approach helps students build real-world version-control and code-review habits while reducing instructor overhead. ## Building a Course Structure with Groups - Dame organizes the university in a root group such as `UWTeaching`, with one subgroup per course, such as `css430`. - Course subgroups contain: - Private lecture materials and code repositories - Student subgroups - Grader subgroups - Permissions inherit through the hierarchy, allowing instructors to control access centrally. - Students receive Reporter access with an expiration date tied to the academic quarter. - They can clone and pull assignment repositories but cannot push to instructor-controlled repositories. - Students use SSH keys across local machines, cloud shells, and virtual machines, then copy code into private repositories for their own version history. ## Automating Enrollment for Large Classes - Manually creating student accounts and permissions becomes impractical for large cohorts. - GitLab’s REST API can automate: - Creating personal subgroups for students - Looking up GitLab users - Assigning Reporter permissions - Setting membership expiration dates - GitLab also provides an open source class-management project with additional automation tools. ## Feedback Through Merge Requests - Students submit assignments by opening merge requests in their repositories. - Instructors immediately see a complete diff of the student’s work. - Comments can be attached directly to individual lines of code. - Inline feedback lets instructors explain both what is wrong and why, while directing students toward the next step. - Because feedback appears beside the relevant code, it is more actionable than comments on a separate document. ## Starting with GitLab for Education - The initial setup requires planning, but the workflow becomes largely self-sustaining once established. - GitLab for Education provides qualifying institutions with GitLab Ultimate features, including expanded storage, compute minutes, and merge-request capabilities. - Instructors are advised to begin with one course group, one assignment template, and a basic pipeline before expanding. A simple GitLab structure can make course administration more efficient while giving students practical experience with the collaborative development tools used in industry.

Read original(opens in new tab)

Database DesignGitlabOpen SourcePython+3

gitlab·Apr 29, 2026·2 min readCurated summary

GitLab Patch Release: 18.11.2, 18.10.5 | GitLab Docs

GitLab released patch versions 18.11.2 and 18.10.5 on April 29, 2026, for Community and Enterprise Editions. The releases address an observability gap affecting disaster recovery RTO/RPO commitments for GitLab Dedicated and fix several regressions and bugs. No security fixes are included. ## Changes in GitLab 18.11.2 - Reverts the `ia-refactor-role-permission-enablement` merge. - Adds Code Suggestions to DAP-supported features for self-hosted models. - Preserves DAP code review access for Duo Core users. - Clears persisted filters when loading the `/work_items` page. - Adds a GraphQL mutation for retrying failed reassignment operations. - Resolves Sidekiq spikes when users are banned. - Fixes MCP OAuth discovery for installations using relative URLs. - Adds the `*_oldest_unsynced_time` metric. - Includes additional changes related to disaster recovery observability. ## Changes in GitLab 18.10.5 - Adds Code Suggestions support for self-hosted models through DAP. - Updates the Duo CLI version used for remote flows. - Skips three migrations that reference dropped tables. - Preserves DAP code review access for Duo Core users. - Resolves Sidekiq spikes caused when users are banned. - Fixes missing `model_definitions` in self-hosted feature settings. - Prevents `CreateOrUpdateDefaultTrackedContextWorker` from running on Geo secondaries. - Adds the `*_oldest_unsynced_time` metric. ## Upgrade and migration impact - **Single-node installations:** Expect downtime because migrations must finish before GitLab starts. - **Multi-node installations:** Zero-downtime procedures can allow upgrades without downtime. - **Regular migrations:** Included in version 18.10.5. - **Post-deploy migrations:** Included in both 18.11.2 and 18.10.5. Administrators should follow GitLab’s standard upgrade guidance for single-node systems and zero-downtime procedures for multi-node deployments before updating.

Read original(opens in new tab)

ObservabilityGitlabGraphQLDatabase Migrations+4

gitlab·Apr 28, 2026·3 min readCurated summary

How to build CI/CD observability at scale

CI/CD observability is essential for improving pipeline performance at enterprise scale, particularly in self-managed GitLab environments. The post presents a containerized solution built with `gitlab-ci-pipelines-exporter`, Prometheus, Grafana, and Node Exporter to turn pipeline and infrastructure data into actionable insights. Its conclusion is that centralized dashboards help teams identify bottlenecks, plan runner capacity, and measure delivery performance. ## Defining CI/CD Performance - Teams should first determine: - Which metrics matter, such as pipeline duration, job success rates, queue times, and runner utilization. - Who needs access, including developers, DevOps engineers, platform teams, and leadership. - Which decisions the data will support, such as infrastructure investment, bottleneck remediation, and capacity planning. ## Observability Architecture - The solution uses two exporters: - **Pipeline Exporter:** Collects pipeline duration, job status, and deployment metrics through the GitLab API. - **Node Exporter:** Collects host CPU, memory, and disk metrics for infrastructure correlation. - Prometheus gathers and stores the metrics. - Grafana provides real-time and historical dashboards. - Dashboards are provisioned automatically through Grafana’s file-based provisioning and can be filtered by project, branch, or time range. ## Grafana Dashboards - **Pipeline Overview:** Displays pipeline volume, success and failure rates, cancelled runs, and average duration trends. - **Job Performance:** Shows job-duration histograms, the ten slowest jobs, and failure heatmaps by project and stage. - **Runner & Infrastructure:** Correlates runner queue times with CPU, memory, and disk usage to support capacity planning. - **Deployment Frequency:** Tracks deployment counts and durations by environment, supporting DORA-style delivery analysis and detection of environment drift. ## Kubernetes Deployment - The recommended enterprise deployment runs each component as a separate workload in a dedicated `gitlab-observability` namespace. - A Kubernetes secret stores the GitLab personal access token, which requires the `read_api` scope. - The Pipeline Exporter runs as a Deployment with a service on port `8080`. - Node Exporter runs as a DaemonSet so each node can expose host metrics on port `9100`. - Prometheus and Grafana are deployed alongside the exporters and configured to scrape and visualize their metrics. - Kubernetes deployment supports existing cluster infrastructure, secrets managers, network policies, and scalable operations. ## Prerequisites - GitLab Self-Managed 18.1 or later. - Kubernetes for enterprise deployments, or Docker/Podman for smaller environments and proof-of-concept testing. - A GitLab personal access token with `read_api` permissions. - Secure secret-management practices, preferably using external secret operators in production. The practical recommendation is to begin with clearly defined performance questions, then deploy the exporter–Prometheus–Grafana stack in a controlled namespace. Combining pipeline data with host metrics provides the context needed to distinguish inefficient jobs from infrastructure capacity problems.

Read original(opens in new tab)

KubernetesObservabilityCI/CDGitlab+4

gitlab·Apr 28, 2026·2 min readCurated summary

GitLab and Anthropic: Governed AI for enterprise development

GitLab is expanding its integration with Anthropic Claude to provide enterprise teams with more capable AI inside a governed software development platform. Claude supports GitLab Duo Agent Platform features such as code generation, review, agentic chat, and vulnerability resolution. The central argument is that organizations should not have to trade advanced AI capabilities for security, compliance, and auditability. ## Governed AI across the SDLC - Claude-generated changes follow GitLab’s existing merge request process, approval rules, security scans, and audit trails. - AI agents do not bypass controls; their actions remain attributable, reviewable, and subject to policy enforcement. - This governance becomes increasingly important as agents autonomously plan, code, test, secure, and deploy software. - GitLab positions built-in governance as a core architectural differentiator rather than an added feature. ## Flexible enterprise deployment - Claude is available in GitLab through: - Google Cloud Vertex AI - Amazon Bedrock - Organizations can use existing cloud contracts, governance frameworks, and data-residency arrangements. - GitLab’s availability in the Claude Marketplace lets customers purchase GitLab Credits and apply them toward Anthropic spending commitments. - These options simplify procurement and consolidate AI spending. ## Supporting an agentic development model - GitLab is selecting model partners based on reasoning ability, reliability, and safety. - The platform is designed to maintain visibility into what AI agents do, when they act, and how their changes are tracked. - As agents take on more complex engineering tasks, GitLab argues that strong models must be paired with equally strong governance. ## Implications for customers - Existing GitLab Duo users gain deeper Claude-powered assistance without changing their established governance processes. - Organizations evaluating AI development platforms can access advanced models while retaining enterprise control. - GitLab presents the integration as a way to accelerate development without compromising compliance or oversight. The practical recommendation is to evaluate AI platforms not only by model capability, but also by how well they integrate governance, auditability, cloud deployment options, and existing enterprise workflows.

Read original(opens in new tab)

Machine LearningGitlabDevSecOpsSoftware Development+4

gitlab·Apr 27, 2026·3 min readCurated summary

Give your AI agent direct GitLab access with glab CLI

The post argues that connecting AI agents to GitLab through the `glab` CLI gives them reliable, current, structured project data instead of forcing them to rely on copied UI content or stale assumptions. Through Model Context Protocol (MCP), agents can inspect issues, merge requests, discussions, and pipelines, then take actions such as commenting or resolving review threads. This reduces friction and enables faster code review and issue triage. ## Why AI Agents Need Direct GitLab Access - Without direct access, agents may: - Hallucinate issue or merge request details. - Rely on outdated training data. - Require developers to manually copy information from GitLab. - `glab` lets agents fetch live project data, act on it, and report results. - The approach supports tools such as GitLab Duo, Claude, Cursor, and other AI assistants. ## Connecting an Agent Through MCP - Model Context Protocol allows AI tools to discover and use external capabilities at runtime. - Start the `glab` MCP server with: ```bash glab mcp serve ``` - Once configured, an agent can answer questions such as: - “What’s the status of my open merge requests?” - “Are there failing pipelines on `main`?” - When used through MCP, `glab` automatically adds `--output json` where supported, giving agents clean, structured responses. - Interactive commands are excluded from MCP so agents do not hang waiting for terminal input. - The implementation uses the official MCP SDK for compatibility with protocol changes. ## Using AI for Merge Request Review - Agents can inspect unresolved review feedback with: ```bash glab mr view 2677 --comments --unresolved --output json ``` - The response includes: - Merge request metadata and description. - Labels and author information. - Unresolved discussions and reviewer comments. - Whether blocking discussions remain unresolved. - The agent can turn this data into a prioritized list of required fixes and suggested changes. ## Resolving Review Discussions Programmatically - Agents can list discussions in structured form: ```bash glab mr note list 456 --output json ``` - After verifying that feedback has been addressed, they can resolve a discussion: ```bash glab mr note resolve 456 3107030349 ``` - Discussions can be reopened when further review is needed: ```bash glab mr note reopen 456 3107030349 ``` - Discussion IDs are available in the GitLab UI and API, so no additional lookup is required. ## Feeding AI Better GitLab Context Without MCP - Even without an MCP server, developers can use `glab` to provide agents with richer, more accurate data. - Instead of pasting a short summary such as issue counts, milestones, and labels, command output can provide structured issue, merge request, or pipeline details. - This gives the agent more context for triage and debugging while avoiding manual browser-based copying. ## Practical Recommendation Use `glab` as the structured interface between GitLab and AI agents. MCP is the most capable option for agents that need to query and modify GitLab directly, while ordinary JSON-producing `glab` commands are a useful fallback for supplying accurate context manually.

Read original(opens in new tab)

Machine LearningModel Context ProtocolCode ReviewJson+3

gitlab·Apr 24, 2026·2 min readCurated summary

curl removed from Omnibus-GitLab FIPS packages in 19.0

GitLab will remove its bundled curl from Omnibus-GitLab FIPS packages beginning with version 19.0 and use the customer’s Linux distribution package instead. The change is driven by curl 8.18.0 dropping support for OpenSSL 1.x and extends GitLab’s existing approach of relying on distribution-provided cryptographic libraries. GitLab instances should continue working normally, but customers will become responsible for keeping curl updated. ## Change to FIPS Packages - Starting with Omnibus-GitLab 19.0, FIPS packages will no longer include a GitLab-built curl. - The package will use curl supplied by the customer’s Linux distribution. - The change applies to all FIPS customers and will also be included in patch releases for existing supported versions. - GitLab 19.0 is scheduled for May 21, 2026. ## Why GitLab Is Making the Change - curl 8.18.0 deprecated compilation against OpenSSL 1.x. - This prevents GitLab’s previous curl-building approach on: - Amazon Linux 2 - AlmaLinux 8 - RHEL 8 environments - FIPS packages already use distribution-provided OpenSSL rather than bundled cryptographic libraries. - GitLab is extending that model to curl for maintainability and security, including on systems using OpenSSL 3.0 or newer. ## Customer Responsibilities - No immediate configuration or migration action is required. - Customers must keep their operating system’s curl package updated to receive security fixes. - Security scanners will report the host OS curl version instead of a GitLab-bundled version. - GitLab will no longer ship curl-specific security updates for FIPS packages. Customers experiencing problems should report them in the Omnibus-GitLab issue tracker.

Read original(opens in new tab)

GitlabDevSecOpsLinuxCurl+3

gitlab·Apr 22, 2026·3 min readCurated summary

GitLab AI Hackathon 2026: Meet the winners

Nearly 7,000 developers participated in GitLab’s 2026 AI Hackathon, creating more than 600 agents and workflows for the GitLab Duo Agent Platform. The winning projects focused on practical software delivery challenges—including organizational knowledge loss, security, compliance, migrations, and sustainability—rather than simple chatbot interactions. The results suggest that agentic AI is becoming most valuable when integrated directly into development workflows and given richer project context. ## Hackathon Scope and Evaluation - The hackathon ran from February 9 to March 25, 2026, on Devpost. - Google Cloud and Anthropic co-sponsored the event, contributing judges, prizes, and cloud resources. - Nineteen judges evaluated projects on: - Technical execution - Design - Potential impact - Quality of the idea - Total prizes reached $65,000. ## Grand Prize: LORE - LORE, or Living Organizational Record Engine, addresses the loss of institutional knowledge when engineers leave. - It combines: - Eight specialized agents - A router that directs questions to the appropriate agent - Protections against circular loops in its knowledge graph - A visual dashboard - Carbon tracking - Its command-line tool includes 43 tests, leading judges to describe it as a polished product rather than a typical hackathon prototype. ## Google Cloud and Anthropic Winners - **Gitdefender**, the Google Cloud Grand Prize winner, detects security issues during code review, writes fixes, and opens the review automatically. - **Aegis**, the Google Cloud Runner Up, explains the reasoning behind its AI decisions and is deployed on Google Cloud. - **GraphDev**, the Anthropic Grand Prize winner, maps code relationships and shows how systems evolve, helping developers understand the impact of changes. - **DocSync**, the Anthropic Runner Up, uses Detector, Writer, and Reviewer agents to update documentation. It opens a review when confident and creates an issue for human review when uncertain. ## Category Winners - **Time-Traveler**, winner for technical achievement, creates a safe copy of a production environment and runs database migrations against it using five connected agents, PostgreSQL, real data, and Google Cloud deployment. - **RedAgent**, the most impactful project, verifies AI-generated security findings before developers act on them, addressing distrust in automated reports. - **Launch Control**, recognized for ease of use, combined polished user experience, strong infrastructure, and sustainability considerations. ## Sustainability-Focused Projects - Five projects received sustainability prizes or bonuses as the organizers highlighted the growing energy cost of CI/CD systems and large language models. - **GreenPipe** analyzes CI/CD pipelines and generates carbon-footprint reports. - Sustainable Design bonuses recognized projects including: - **BugFlow**, which generated 10 fixes from one bug report in 20 minutes - **DELTA Cyber Reasoning**, an automated fuzz-testing tool - **CarbonLint**, which applies code analysis to energy consumption - **TFGuardian**, which includes carbon-footprint analysis - One project reduced monthly costs from $556 to $18, representing a reported 96% carbon reduction. ## Honorable Mentions - **SecurityMonkey** tests security scanners by injecting known vulnerabilities. - **stregent** enables CI/CD investigation and fixes through WhatsApp. - **Compliance Sentinel** evaluates merge requests for compliance risk and blocks critical violations. - **Carbon Tracker** measures the carbon footprint of individual pipeline jobs and suggests improvements. - **RepoWarden** captures the rationale behind code, not only its behavior. - **MR Compliance Auditor** maps merge-request evidence to SOC 2 controls and displays compliance scores in real time. ## What Comes Next The projects operated within a single GitLab project, but many teams supplemented their agents with local knowledge graphs to understand code relationships and dependencies. GitLab plans to build on this approach in future hackathons by providing agents with richer context. GitLab’s hackathon demonstrates that the strongest AI agents are workflow-integrated tools that can investigate, make decisions, execute changes, and involve humans when needed. Developers can explore the 600-plus projects in the gallery or build their own agents on the GitLab Duo Agent Platform.

Read original(opens in new tab)

Database DesignMachine LearningCI/CDGitlab+4

gitlab·Apr 22, 2026·3 min readCurated summary

GitLab Patch Release: 18.11.1, 18.10.4, 18.9.6 | GitLab Docs

GitLab released patch versions 18.11.1, 18.10.4, and 18.9.6 on April 22, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. Self-managed installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes include unauthenticated GraphQL and browser-based attacks, several denial-of-service flaws, and access-control weaknesses. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affects all deployment types unless otherwise specified, including Omnibus, source installations, and Helm charts. - Recommended fixed versions: - 18.11.1 - 18.10.4 - 18.9.6 - GitLab issues detailing security vulnerabilities are made public 30 days after the relevant patch release. - GitLab publishes both scheduled patch releases, issued on the second and fourth Wednesdays, and ad-hoc critical patches for high-severity vulnerabilities. ## High-Severity Vulnerabilities - **CVE-2026-4922 — GraphQL CSRF** - CVSS 8.1. - An unauthenticated attacker could execute GraphQL mutations on behalf of an authenticated user because of insufficient CSRF protection. - Affects versions before 18.9.6, 18.10.4, and 18.11.1. - **CVE-2026-5816 — Web IDE path validation** - CVSS 8.0. - Under certain conditions, improper path validation could allow unauthenticated attackers to execute arbitrary JavaScript in a user’s browser session. - Affects the 18.10 and 18.11 release lines before the listed patches. - **CVE-2026-5262 — Storybook cross-site scripting** - CVSS 8.0. - Improper input validation could allow unauthenticated access to tokens in the Storybook development environment. - Affects versions from 16.1 through the unpatched 18.9, 18.10, and 18.11 releases. ## Denial-of-Service Fixes - **CVE-2025-0186:** Crafted requests to the discussions endpoint could exhaust server resources. - **CVE-2026-1660:** Improper input validation during Jira issue imports could enable resource exhaustion. - **CVE-2025-6016:** Insufficient limits when retrieving notes could cause service disruption. - **CVE-2025-3922:** Resource-allocation weaknesses in the GraphQL API could allow authenticated users to overwhelm the system. - Each issue carries a CVSS score of 6.5 and generally requires authentication. ## Access-Control and Session Fixes - **CVE-2026-6515 — Virtual registry credentials** - CVSS 5.4. - Invalidated or incorrectly scoped credentials could continue accessing Virtual Registries. - **CVE-2026-5377 — Confidential issue titles** - CVSS 4.3. - Authenticated users could potentially view titles of confidential or private issues in public projects. - **CVE-2026-3254 — Mermaid sandbox** - CVSS 3.5. - Improper validation could allow authenticated users to load unauthorized content into another user’s browser. - The release also lists **CVE-2025-9957**, involving improper access control in the project fork relationship API; the provided text does not include its full impact or severity details. Self-managed GitLab administrators should apply the appropriate patch release as soon as possible, especially because several vulnerabilities permit unauthenticated browser or API attacks.

Read original(opens in new tab)

GitlabGraphQLVulnerability ManagementCross Site Scripting+4