Gitlab

98 posts

gitlabMay 21, 20262 min readCurated summary

Track CI component usage across your organization

GitLab 19.0 adds Components Analytics to the CI/CD Catalog, giving organizations visibility into how shared CI/CD components are adopted and which versions projects use. All tiers provide high-level usage counts, while GitLab Ultimate offers project-level version tracking and outdated-version identification. The feature helps platform teams respond to security issues, manage upgrades, and govern increasingly AI-generated pipelines. ## The Visibility Gap in Shared CI - The CI/CD Catalog centralizes versioned, reusable pipeline components. - Previously, maintainers could not easily determine: - Whether components were being used - Which projects depended on them - Which versions were still active - Security fixes did not automatically reach projects using older component versions, making organizational exposure difficult to measure. ## High-Level Adoption Analytics - Available across all GitLab tiers, including Free; introduced in GitLab 18.9. - Found under **Explore > CI/CD Catalog > Analytics**. - Shows, for each maintained catalog resource: - The latest released version - The number of unique projects using it in the past 30 days - Components available in that version - Helps teams prioritize maintenance, plan deprecations, and assess investment in shared CI infrastructure. ## Component Usage Detail in Ultimate - GitLab Ultimate provides per-component drill-down analytics. - Maintainers can see: - Which projects used each component in the past 30 days - The version used by each project - Whether each project is up to date or outdated - This makes it easier to respond to vulnerabilities, notify project owners, open merge requests, and assess the impact of refactors or deprecations. ## Native Governance Compared with Other Platforms - GitHub Actions lacks native organization-wide catalog analytics for reusable workflows. - CircleCI Insights focuses on pipeline performance rather than orb adoption and versions. - Jenkins Shared Libraries require custom tooling to track usage. - GitLab combines a governed component catalog with built-in adoption and version visibility. ## Supporting AI-Generated Pipelines - The catalog establishes standardized CI practices, while analytics verifies whether those standards are actually used. - This is increasingly important as AI tools generate more production pipelines. - Self-Managed and Dedicated customers can mirror GitLab components and combine them with internally built components for regulated or air-gapped environments. Organizations maintaining CI/CD Catalog components can use adoption metrics immediately. Teams needing project-level version and remediation details require GitLab Ultimate.

Gitlab CI/CD DevSecOps Yaml+3

gitlabMay 18, 20263 min readCurated summary

GitLab Dedicated for Government now GovRAMP-authorized

GitLab Dedicated for Government has received GovRAMP Authorization, giving state and local agencies a compliant path to adopt SaaS-based DevSecOps. Its single-tenant, U.S.-based architecture combines data residency, private networking, physical isolation, and managed infrastructure with GitLab’s development, security, and compliance capabilities. The authorization is especially timely as more states move toward mandatory GovRAMP requirements. ## Modernization Meets Security - Government agencies are increasing investments in hybrid- and multi-cloud modernization. - NASCIO’s 2025 survey ranked modernization as a top priority for state CIOs. - Agencies must modernize while addressing: - Aging IT systems and security gaps - Third-party software supply-chain risks - Ransomware and nation-state threats - Limited budgets and staffing - GitLab Dedicated for Government is designed to provide infrastructure control and compliance without requiring agencies to build and operate the underlying platform. ## GovRAMP Authorization - GovRAMP provides a standardized security and compliance assessment for state and local government cloud services. - Thirty-two states have adopted GovRAMP, with several moving toward mandatory requirements. - Authorization reduces a major procurement barrier for agencies seeking secure DevSecOps platforms. - GitLab Duo is available within the authorized environment, while GitLab Duo Agent Platform is planned for later in 2026. ## Toolchain Consolidation - Public-sector teams often use more than five development tools and more than five security tools, increasing cost, complexity, and attack surface. - Tool sprawl also creates collaboration barriers; surveyed teams reported losing roughly six hours per week to inefficient processes. - GitLab Dedicated for Government consolidates development, security, and compliance workflows on one platform. - Centralized access controls support zero-trust implementation and consistent security policies. - Open APIs and integrations allow agencies to consolidate tools gradually rather than requiring an immediate replacement of existing systems. ## Data Residency and Protection - The platform runs on GovRAMP-authorized infrastructure with data access restricted to U.S. citizens. - Private connections can link an agency’s virtual private cloud to its isolated GitLab instance without exposing services directly to the public internet. - Data is encrypted in transit and at rest. - Customers may use their own AWS Key Management Service key to control encryption for stored data. - GitLab continuously patches vulnerabilities and CVEs, reducing the infrastructure and compliance workload for agency teams. ## Managed, Single-Tenant Hosting - Each customer receives a physically isolated, single-tenant environment. - The service is U.S.-based, privately connected, and fully managed by GitLab. - Agencies can focus staff on mission priorities instead of infrastructure operations. - GitLab argues that managed hosting can provide faster time-to-value and lower total cost of ownership than self-hosting, while improving developer productivity, delivery speed, security, and compliance. ## Native Security and Compliance - Security and compliance capabilities are integrated throughout the software development lifecycle. - Built-in scanners include: - Static application security testing - Secret detection - Container scanning - Dynamic application security testing - Dependency scanning covers both direct and transitive dependencies without depth limits. - Results are available at the project and group levels, helping teams identify supply-chain risks across applications. - Findings appear directly in merge requests and pipeline security views for contextual, one-click triage. - Custom rulesets and automated security policies help reduce false positives and standardize enforcement. GitLab Dedicated for Government offers agencies a managed alternative to self-hosted DevSecOps while preserving stronger control over residency, isolation, networking, encryption, and compliance. For state and local governments preparing for stricter GovRAMP requirements, it provides a practical foundation for modernization without sacrificing security or operational control.

Gitlab DevSecOps Cloud Security Software Supply Chain Security+4

gitlabMay 18, 20263 min readCurated summary

Fix bugs with Codex and GitLab

Codex accelerates coding in the terminal, but producing a fix is only one part of shipping software. GitLab supplies the surrounding lifecycle: issues, merge requests, CI/CD, security scanning, code review, and human approval. The tutorial demonstrates this progression through a Rust WebSocket bug, first with local Codex, then with GitLab MCP for issue context, and finally with Codex as an external agent in GitLab Duo Agent Platform. ## Prerequisites and Project Setup - Configure Codex in the terminal, Rust/Cargo, and access to a GitLab project. - Import and clone the Tanuki IoT Platform project, then launch Codex from its repository root. - The tutorial focuses on `backend/`, where: - Sensors submit readings through a REST API. - Dashboards receive live readings through WebSocket streams. - `AGENTS.md` provides Codex with repository structure, toolchain instructions, build commands, and quality expectations. ## Reproducing the WebSocket Filtering Bug - Start the Rust metrics backend on port `9090`: ```bash PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml ``` - Connect to a filtered WebSocket stream: ```bash websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius' ``` - Submit both temperature and humidity readings for the same sensor through the REST API. - The stream incorrectly returns both metrics instead of only `temperature_celsius`, proving that the WebSocket handler does not apply the metric filter. ## Fixing the Bug with Codex - Give Codex a focused request to add metric filtering to `/ws`. - Codex examines the Rust source and identifies that the endpoint already supports `sensor` filtering but lacks an optional `metric` condition. - It updates the handler, adds tests, and keeps documentation aligned with the implementation. - Codex runs formatting, tests, and builds before creating a branch, committing, and pushing the change. - Once the merge request is created, GitLab handles: - CI/CD pipelines - Security scanning - GitLab Duo Code Review - A follow-up WebSocket test confirms that supplying both sensor and metric now returns only the requested metric. ## Adding GitLab Context with MCP - Local Codex can inspect repository files, but it cannot automatically see GitLab issues, requirements, implementation notes, merge-request discussions, or pipeline status. - The GitLab MCP server connects Codex to that development lifecycle context. - Codex can retrieve the existing issue directly instead of requiring the developer to copy its contents into the prompt. - The issue acts as the shared source of truth and includes: - The bug description - Functional behavior requirements - Non-functional requirements - Required tests - Updates to `README.md` and `AGENTS.md` - Implementation notes - This helps Codex produce a fix that satisfies the agreed requirements rather than merely addressing the symptom visible in the local code. ## Using Codex as an External GitLab Agent - The tutorial’s third workflow uses Codex inside GitLab Duo Agent Platform as an external agent. - This allows the agent to participate after the merge request is open, particularly when addressing review feedback. - GitLab remains the system coordinating issues, merge requests, pipelines, reviews, and deployment, while Codex contributes its terminal-oriented coding capabilities. - The overall workflow moves from bug report to implementation, automated validation, review feedback, revisions, and an informed human decision to ship. ## Practical Conclusion Use Codex for fast, repository-local implementation, but connect it to GitLab through MCP or Duo Agent Platform when requirements and review context matter. The strongest workflow combines Codex’s coding speed with GitLab’s issue-aware, automated, and human-governed delivery lifecycle.

Gitlab AI Agents CI/CD Rust+3

gitlabMay 13, 20262 min readCurated summary

5 ways to fix misleading vulnerability severities with policy

CVSS scores describe a vulnerability’s general characteristics, not its actual risk in a specific environment. GitLab severity override policies let teams automatically adjust findings based on CVE, CWE, file path, or directory, reducing manual triage. The result is a vulnerability report that better reflects deployment context, exploitability, and organizational priorities. ## How Severity Override Policies Work - Policies run automatically on every default-branch pipeline. - Rules match findings by: - CVE identifier - CWE identifier - File path - Directory - Available actions: - **Set Severity** to informational, low, medium, high, or critical - **Increase Severity** by one level - **Decrease Severity** by one level - Manual overrides by authorized users take precedence. - GitLab records automated changes in vulnerability history and audit events. ## Downgrading Low-Risk CVEs in Internal Services - Internal tools and services may have substantially lower exposure than public-facing applications. - A policy can reduce the severity of selected CVEs found under paths such as `internal/**/*`. - The `decrease` operation lowers severity by one level—for example, Critical to High or High to Medium. - Teams should replace the example CVEs with vulnerabilities they have assessed as less risky in internal deployments. ## Upgrading Injection Vulnerabilities in Production Code - XSS (`CWE-79`) and SQL injection (`CWE-89`) are frequently exploited vulnerability classes. - Findings involving these CWEs under `src/**/*` can be forced to **Critical**. - Combining this override with a merge request approval policy can require security-team review before affected code reaches production. ## Normalizing Severity Across Scanners - SAST, dependency, and container scanners may assign different severities to the same CVE. - A policy can set specific vulnerabilities—such as Log4Shell-related CVEs—to a consistent baseline, such as High. - This produces more predictable triage and approval thresholds across scanning tools. ## Incorporating Exploitation Intelligence - CVSS is largely static and does not reflect changes in real-world exploitation. - EPSS and CISA’s Known Exploited Vulnerabilities catalog provide signals about exploitation likelihood and active attacks. - Teams can explicitly upgrade CVEs identified as actively exploited or highly likely to be exploited, treating them as Critical regardless of their original scanner rating. GitLab severity overrides are most useful when they encode a documented risk model: deployment exposure, vulnerability type, scanner consistency, and current threat intelligence. They should complement—not replace—manual review, auditability, and merge request approval controls.

Gitlab Vulnerability Management Yaml Sast+4

gitlabMay 13, 20262 min readCurated summary

GitLab Patch Release: 18.11.3, 18.10.6, 18.9.7 | GitLab Docs

On May 13, 2026, GitLab released patch versions 18.11.3, 18.10.6, and 18.9.7 for CE and EE. The releases address multiple high-severity security vulnerabilities, including cross-site scripting, denial of service, authorization, and access-control issues. GitLab strongly recommends that all affected self-managed installations upgrade immediately. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - GitLab.com is already patched; GitLab Dedicated customers do not need to act. - Patch releases may be scheduled or issued urgently for critical vulnerabilities. - Security vulnerability details are published publicly 30 days after the fixing release. - Unless otherwise specified, all deployment types—including Omnibus, source installations, and Helm charts—are affected. ## Cross-Site Scripting Vulnerabilities Several authenticated-user XSS vulnerabilities could allow arbitrary JavaScript to execute in other users’ browsers: - **CVE-2026-7481**: Affects EE Analytics dashboard chart rendering; exploitable by users with Developer permissions. - **CVE-2026-5297**: Affects global search in CE and EE. - **CVE-2026-6073**: Affects EE Duo Agent output rendering. - **CVE-2026-7377**: Affects customizable EE Analytics dashboards. - Each issue received a **CVSS score of 8.7** and resulted from improper input sanitization. ## Denial-of-Service Vulnerabilities The release fixes multiple unauthenticated denial-of-service issues involving malformed requests or files: - **CVE-2026-1659**: Specially crafted requests to the CI/CD job update API could disrupt service. - **CVE-2025-14870**: Malformed JSON payloads targeting the Duo Workflows API could cause a denial of service. - **CVE-2025-14869**: Certain internal API endpoints were vulnerable to specially crafted payloads. - **CVE-2026-1184**: A specially crafted file uploaded through Insights Configuration could cause service disruption. - The API-related issues were rated **CVSS 7.5**; the Insights issue was rated **6.5**. ## Authorization and Access-Control Issues - **CVE-2026-1322**: An authenticated user with a `read_api`-scoped OAuth application could create issues and comment on private projects through GraphQL, due to improper token-scope enforcement. It received a **CVSS score of 6.8**. - **CVE-2026-4524**: Authenticated users could access confidential issue content in public projects through the Issues API without proper authorization checks. It received a **CVSS score of 6.5**. ## Recommended Action Self-managed GitLab administrators should upgrade to the latest supported patch release—18.11.3, 18.10.6, or 18.9.7—as soon as possible, particularly because several vulnerabilities are remotely exploitable and require little or no authentication.

Gitlab JavaScript GraphQL Oauth+3

gitlabMay 13, 20262 min readCurated summary

Harden your pipeline perimeter for the era of AI-assisted coding

AI-assisted coding brings humans, agents, and third-party code together in the software pipeline, increasing the speed at which vulnerabilities can be introduced. The post argues that security tools must become part of the development workflow rather than separate portals. GitLab Ultimate presents this as a three-part control plane: see every risk, automatically enforce policy, and help developers fix vulnerabilities in context. ## See Every Project, Risk, and Action - The Group Security Dashboard consolidates SAST, SCA, secret detection, container, IaC, DAST, and fuzz-testing results across projects. - Security Inventory identifies projects that have never been scanned, exposing governance gaps hidden by project-level dashboards. - Credentials Inventory tracks tokens, owners, scopes, expiration, and revocation status, enabling rapid response to compromised credentials. - Token Lifetime Enforcement applies mandatory maximum lifetimes to tokens. - Audit Event Streaming sends events such as token creation, permission changes, MR approvals, and role updates to SIEM systems in real time. - Group-wide SBOM search helps identify open-source dependency exposure across the project portfolio. ## Enforce Policies Automatically - Scan Execution Policies inject mandatory SAST, SCA, and secret-detection jobs into production pipelines and prevent removal or bypass through configuration such as `[skip ci]`. - Pipeline Execution Policies enforce platform-owned CI templates, closing gaps created by ungoverned or “shadow” pipelines. - MR Approval Policies automate requirements for protected branches, approvers, and code owners. - The Compliance Center maps controls to SOC 2, ISO 27001, NIST, and PCI DSS while providing live dashboards and audit trails. - Secret Push Protection rejects credentials before they enter Git history and records bypass attempts. ## Fix Vulnerabilities in the Development Workflow - The MR security widget displays SAST, SCA, container, IaC, and secret findings directly alongside code changes before they reach the default branch. - Advanced SAST uses cross-file taint analysis to trace untrusted input from source to sink. - GitLab Duo helps identify likely false positives and explain the reasoning behind its assessment. - The Duo Security Analyst Agent prioritizes issues using exploitability, exposure, and business context in addition to CVSS. - Agentic Vulnerability Resolution can create fix merge requests for high-impact SAST findings, allowing developers to review and merge changes through the normal approval process. The practical recommendation is to make security controls native to the pipeline. For organizations adopting AI-assisted development, GitLab Ultimate’s integrated visibility, automated enforcement, and AI-supported remediation are presented as a way to maintain security without sacrificing delivery speed.

Gitlab CI/CD DevSecOps Sast+4

gitlabMay 11, 20264 min readCurated summary

GitLab Act 2

GitLab is restructuring its organization and strategy to prepare for an agent-driven software industry. It expects AI agents to dramatically increase software production, making scalable infrastructure, orchestration, context, and governance more important than traditional developer tooling. The company is reducing geographic footprint and management layers while reorganizing R&D around smaller, autonomous teams, reaffirming its FY27 guidance pending final restructuring costs. ## Organizational Restructuring - GitLab is conducting the process openly, including a voluntary separation window. - The new organizational shape is expected to be finalized by June 1 where possible; local legal processes may extend timelines. - Planned operational changes include: - Reducing the number of countries with small GitLab teams by up to 30%, while relying on partners in affected markets. - Removing up to three management layers in some functions. - Reorganizing R&D into approximately 60 smaller teams with end-to-end ownership. - Automating internal reviews, approvals, and handoffs with AI agents, then adjusting roles accordingly. - The restructuring and strategic shift are related but independently justified. - GitLab will disclose the restructuring’s final scope and financial impact during its June 2 earnings call. ## Software Development in the Agentic Era - Software will increasingly be produced by machines under human direction. - Agents will plan, code, review, deploy, and repair software. - Engineers will remain responsible for architecture, customer understanding, judgment, and difficult tradeoffs. - Lower software-production costs are expected to expand demand for software and increase the value of developer platforms. - Deep engineering skills—such as system design, distributed systems, failure analysis, and integrating new capabilities safely—will become more important and scarce. - GitLab points to its Duo Agent Platform, released in January, as an initial investment in this future. ## Infrastructure for Machine-Scale Development - Agents can create merge requests, trigger pipelines, and push commits at volumes far beyond human teams. - Git and existing development platforms were not designed for this level of activity. - GitLab plans to: - Reengineer Git for machine-scale workloads. - Replace parts of its monolithic architecture with API-first, composable services. - Provide agent-specific APIs so agents can interact as first-class platform users. - The company argues that reliability, performance, and scalability at this level will become a major source of platform value. ## Orchestration Across the Software Lifecycle - Enterprises need more than individual agents that generate code or open merge requests; they need software that reaches production and delivers business value. - GitLab’s orchestration layer is intended to coordinate agents across the lifecycle by: - Assigning work and managing state. - Passing context between tasks. - Resolving conflicts. - Enforcing policies and guardrails. - Keeping humans involved where judgment is required. - CI/CD is being reconsidered as part of this shift, with orchestration serving as the runtime for validating and safely deploying machine-rate changes. ## Context as a Competitive Advantage - Code generation capabilities are increasingly similar across developer-tool vendors. - GitLab believes its advantage lies in the connected context accumulated across planning, code, review, security, deployment, and operations. - It plans to make this data model a first-class, API-accessible service. - More contextual information should allow agents to use fewer tokens and produce better results. ## Governance Built Into the Platform - As agents perform more work, enterprises need strong control over identity, permissions, policies, auditing, and data location. - GitLab intends to make governance core infrastructure rather than an add-on product. - Every agent, pipeline, and merge request should operate through platform services that can: - Control who or what may perform an action. - Record what happened and why. - Protect sensitive code and data. - Support flexible deployment models. ## One Platform, Three Modes - GitLab notes that most business software cannot realistically be rewritten for the agentic era. - Its platform strategy is therefore intended to support existing codebases alongside newer development models. - The provided text ends before explaining the three modes in detail. GitLab’s overall recommendation to itself is to reshape both its organization and platform around machine-scale software development, while preserving human control over architecture, judgment, and governance.

Gitlab AI Agents CI/CD Distributed Systems+4

gitlabMay 7, 20263 min readCurated summary

Consolidate your GitLab stack with Gitaly on Kubernetes

Gitaly on Kubernetes is now generally available with GitLab 18.11, allowing teams to run their entire GitLab stack in Kubernetes instead of maintaining Gitaly on separate virtual machines. GitLab addressed Kubernetes-specific challenges involving cgroup isolation, pod restarts, and request reliability. The result is a more unified deployment model, though full high availability still depends on Gitaly Cluster support for Kubernetes. ### Challenges of Running Gitaly on Kubernetes - Git operations can consume unpredictable amounts of memory. - Gitaly isolates individual Git processes in dedicated cgroups so an out-of-memory failure does not bring down the main Gitaly process. - Kubernetes deployments required special handling because containerd traditionally restricted cgroupfs writes to privileged containers. - GitLab solved this by using an init container to mount `/sys/fs/cgroup` and make it writable. ### Handling Pod Restarts - Virtual-machine deployments can upgrade Gitaly in place and reload gracefully while preserving the socket. - Kubernetes StatefulSet replacements cause pods to stop and restart abruptly during upgrades, node drains, or configuration changes. - This could cause downtime, particularly for Gitaly Sharded deployments without built-in high availability. - GitLab made Gitaly client retries configurable, allowing clients such as Rails to retry requests until Gitaly becomes available again. - Users may experience slightly higher latency during restarts, but requests generally succeed without visible downtime. ### Benchmark Results and High Availability - GitLab tested common Git operations against VM-based and Kubernetes-based Gitaly installations during upgrades. - Success rates were nearly identical in both environments despite Kubernetes abruptly terminating pods and closing sockets. - Achieving complete success across every operation still requires Gitaly Cluster with Praefect. - Praefect does not yet support Kubernetes, but Kubernetes support is being developed. ### Benefits for GitLab Deployments - Teams with hybrid infrastructure can move Gitaly from virtual machines into their existing Kubernetes cluster. - This removes the need to maintain and monitor a separate VM fleet. - Organizations adopting GitLab on Kubernetes can use a fully Kubernetes-native deployment through the official Helm chart. - Gitaly can run as part of a complete GitLab installation or as an external component. ### Installation - The recommended deployment method is the GitLab Helm chart. - Users should review the Gitaly on Kubernetes documentation before installation. - The documentation covers configuration guidance, common pitfalls, full installations, and external Gitaly deployments. Gitaly on Kubernetes is a practical option for consolidating GitLab infrastructure and simplifying operations. Teams should use the Helm chart and configure client retries carefully, while recognizing that Kubernetes-based high availability through Praefect is still forthcoming.

Gitlab Kubernetes Git Gitops+4

gitlabMay 7, 20262 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.

Gitlab GraphQL Rest Api Api Security+3

gitlabMay 6, 20263 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.

Gitlab Code Review Claude Code C Plus Plus+4

gitlabMay 5, 20263 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.

Gitlab AI Agents DevSecOps Governance+3

gitlabMay 4, 20263 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.

Gitlab Cloud Computing Jira Data Privacy+3

gitlabApr 29, 20262 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.

Gitlab Database Design Open Source Python+3

gitlabApr 29, 20262 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.

Gitlab Observability GraphQL Database Migrations+4

gitlabApr 28, 20263 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.

Gitlab Kubernetes Observability CI/CD+4