GitLab/devops

10 posts

gitlab

Green DevOps: Why carbon measurement belongs in your CI/CD pipeline (opens in new tab)

CI/CD pipelines consume energy and generate emissions that standard pipeline metrics do not reveal. The post argues that measuring this impact is the first step toward reducing it, recommending Eco CI for job-level measurements and Carmen for infrastructure and application-level analysis. Both tools integrate with GitLab pipelines with minimal effort and can improve sustainability, performance, and cloud costs. ## Why CI/CD Carbon Measurement Matters - Modern teams run hundreds of jobs daily, including increasingly resource-intensive AI-assisted testing and automation. - Each job has an energy and carbon cost that is usually absent from pipeline logs and architecture diagrams. - Green DevOps involves measuring emissions per pipeline, service, and Kubernetes workload to guide engineering decisions. ## Measuring Emissions at Different Layers ### Pipeline-level measurement with Eco CI - Eco CI measures energy consumption and carbon emissions for individual CI/CD jobs. - It runs as lightweight Bash scripts without additional servers or databases. - Teams can identify expensive jobs, track emissions over time, and add a carbon badge to a project README. - Because it works within existing pipelines, it is a practical starting point. ### Infrastructure and application measurement with Carmen - Carmen, the Carbon Measurement Engine, uses the Green Software Foundation Impact Framework. - It measures emissions from virtual machines, Kubernetes pods, and application workloads. - Reports are provided per component in CSV format and distinguish: - Operational carbon from energy consumption - Embodied carbon from hardware manufacturing and disposal - Outputs such as `EnergykWh` and `TotalCarbonGramsCO2eq` can be imported into Grafana, FinOps dashboards, or custom tools. - Carmen helps teams compare emissions across services, such as an API gateway versus a data-processing layer. ## Adding Carbon Reports to GitLab - Both tools can be integrated through `.gitlab-ci.yml`. - A Carmen job can: - Use a Python 3.12 image - Install Node.js, npm, Git, and the Impact Framework toolchain - Clone and install the Carmen project - Run `carbon-daemon` - Store generated reports as GitLab artifacts - Carmen can run as a separate, non-blocking job, keeping carbon measurement outside the critical delivery path. ## Turning Visibility into Engineering Improvements - Eco CI may reveal that integration tests produce unusually high emissions because dependencies are reinstalled on every run. - Adding dependency caching can reduce runtime, emissions, and CI costs without architectural changes. - Carmen can expose idle infrastructure, such as deprecated services still running in a staging Kubernetes cluster. - Decommissioning unused workloads eliminates both their operational and embodied carbon costs. ## Business and Regulatory Benefits - Emissions data creates a baseline for future reporting requirements, even when a company’s absolute footprint is relatively small. - Carbon-efficient systems are often faster and cheaper because they use fewer compute resources. - Caching, right-sizing runners, and removing idle services support both sustainability and FinOps goals. - Regulations such as the EU’s CSRD, along with enterprise procurement requirements, are increasing pressure for supply-chain and cloud-emissions reporting. Teams can start with Eco CI on one GitLab pipeline, then add Carmen for infrastructure-level visibility. Measuring carbon alongside runtime and cost makes sustainability a practical part of everyday engineering rather than a separate initiative.

gitlab

Introducing the 2026 EMEA GitLab Partner Award winners (opens in new tab)

GitLab announced its 2026 EMEA Partner Award winners, recognizing organizations that drove customer success, technical innovation, certification, business growth, and joint marketing. The awards highlight partners helping enterprises adopt DevSecOps, cloud-native platforms, managed services, and AI-enabled software development across the region. ## Regional Partners of the Year - **Central Europe: cc cloud GmbH** — Combines infrastructure and DevOps expertise to manage cloud applications, platforms, and IT operations. - **Northern Europe: Eficode** — Supports more than 1,600 customers through consulting, managed services, toolchain implementation, and AI-augmented development. - **Southern Europe: Kiratech** — Helps enterprises modernize infrastructure using cloud-native, DevOps, and PlatformOps practices. - **Eastern Europe and Israel: Bynet** — An established systems integrator supporting enterprise IT, cloud, cybersecurity, modernization, DevSecOps, and AI adoption. ## Technical and Enablement Awards - **Best Technical Solution/Project: Capgemini | Sogeti** — Recognized for impactful, complex technical solutions using AI-driven quality engineering, data, and cloud capabilities. - **Most Certified and Enabled Partner: Devoteam** — Awarded for having the largest number of GitLab-certified professionals. - **Rookie of the Year: ITDOTCOM** — A Uzbekistan-based technology distributor that achieved rapid success supporting software, infrastructure, cybersecurity, and business automation across Central Asia. ## Growth and Collaboration Awards - **First Order Master: Linux Polska** — Recognized for winning new customers and business through open-source consulting, DevOps, automation, containerization, and data analytics. - **Co-marketing Partner of the Year: Conoa, a PROACT Company** — Honored for joint marketing efforts and expertise in Kubernetes, cloud-native technologies, container platforms, and managed operations. The awards demonstrate the breadth of GitLab’s EMEA partner ecosystem, from regional systems integrators and cloud specialists to technical consultants and Kubernetes providers. Together, these partners are helping customers modernize delivery practices and adopt DevSecOps and AI capabilities.

gitlab

CI Expert and Data Analyst AI agents target development gaps (opens in new tab)

GitLab 18.11 introduces two Duo Agent Platform agents aimed at development gaps left by faster AI-generated coding. CI Expert Agent helps teams create working pipelines, while Data Analyst Agent answers software delivery questions using GitLab data. Both benefit from being embedded in GitLab, where they can use current repository, pipeline, issue, and merge request context. ## CI Expert Agent: Faster Pipeline Setup - Now available in beta. - Inspects a repository to identify its language, framework, and testing setup. - Generates runnable build and test configurations without requiring developers to write YAML manually. - Explains each pipeline step in plain language through Agentic Chat. - Uses native GitLab CI semantics. - Addresses the common problem of delaying CI because `.gitlab-ci.yml` is difficult to create or validate. - Helps reduce regressions, oversized changes, and dependence on undocumented team knowledge. - Available on GitLab.com, Self-Managed, and Dedicated across Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## Data Analyst Agent: Natural-Language SDLC Queries - Generally available in GitLab 18.11. - Lets users ask questions about development performance in plain language and receive visualizations in Agentic Chat. - Covers merge requests, issues, projects, pipelines, and jobs. - Supports questions about: - MR cycle time and review bottlenecks - Project throughput and contribution patterns - Flaky tests and pipeline performance - Runner utilization and deployment frequency - Cross-portfolio lead times and project health - Eliminates the need to learn GitLab Query Language, request custom dashboards, or rely on separate analytics tools. - Generated GLQL queries can be copied into GitLab Flavored Markdown. - Exporting results to work items and dashboards is planned. - Available across GitLab.com, Self-Managed, and Dedicated Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## The Advantage of Platform-Native Context - Both agents operate within GitLab and can access existing code, pipelines, issues, and merge requests. - Their recommendations and answers are based on current operational data rather than generic examples or disconnected tools. - The agents are designed to support the full lifecycle: understanding code, configuring CI, shipping changes, and evaluating delivery performance. Together, these agents make GitLab Duo more useful beyond code generation. Teams should consider trying CI Expert Agent for faster initial pipeline setup and Data Analyst Agent for immediate, self-service insight into delivery performance.

gitlab

GitLab 18.11 release notes | GitLab Docs (opens in new tab)

Agentic SAST Vulnerability Resolution is now generally available in GitLab 18.11 through the GitLab Duo Agent Platform. It autonomously analyzes critical and high-severity SAST findings, proposes code fixes, and creates ready-to-review merge requests. The feature is designed to accelerate remediation while giving reviewers confidence assessments and the option to apply fixes directly from vulnerability details. ## Availability and Integration - Available with GitLab Ultimate. - Supported on GitLab.com, GitLab Self-Managed, and GitLab Dedicated. - Runs: - As part of a SAST scan - After SAST false-positive detection - Manually for individual SAST vulnerabilities ## Automated Vulnerability Analysis - Examines each finding and reasons through the surrounding code context. - Generates proposed fixes for critical and high-severity SAST vulnerabilities. - Automatically opens a merge request containing the remediation for review. ## Review and Remediation Workflow - Provides quality assessments to help reviewers evaluate the likely reliability of each proposed fix. - Lets users apply resolutions directly from vulnerability details pages. - Feedback is welcomed through GitLab issue 585626. ## Practical Recommendation Teams using GitLab Ultimate can enable the feature to streamline SAST remediation, while still reviewing agent-generated merge requests before merging changes.

gitlab

A guide to the breaking changes in GitLab 19.0 (opens in new tab)

GitLab 19.0 is expected to introduce 15 breaking changes, primarily by removing deprecated components and outdated platform support. The most significant effects involve Helm chart networking and bundled services, OAuth authentication, PostgreSQL, Redis, and supported operating systems. Administrators should audit their deployments and complete migrations before upgrading. ## Release and Deployment Windows - **GitLab.com:** Primary breaking-change window is May 4–6, 2026, with a fallback window on May 11–13. - **GitLab Self-Managed:** GitLab 19.0 becomes available May 21, 2026. - **GitLab Dedicated:** Upgrades occur during assigned maintenance windows, with GitLab 19.0 scheduled for the week of June 22, 2026. - Additional changes may roll out outside these windows in exceptional circumstances. ## High-Impact Changes ### NGINX Ingress Replaced by Gateway API - The GitLab Helm chart will use **Gateway API with Envoy Gateway** as its default networking configuration. - Bundled NGINX Ingress reached end-of-life in March 2026. - Existing deployments can explicitly continue using bundled NGINX Ingress until its planned removal in GitLab 20.0. - The change does not affect: - NGINX used by the Linux package. - Deployments using externally managed Ingress or Gateway API controllers. - Administrators should plan migration to Envoy Gateway or another externally managed controller. ### Bundled PostgreSQL, Redis, and MinIO Removed - The GitLab Helm chart and GitLab Operator will no longer bundle Bitnami PostgreSQL, Bitnami Redis, or the forked MinIO chart. - These components were intended for proof-of-concept and test environments, not production. - Deployments using them must migrate to external services before upgrading. - PostgreSQL and Redis bundled with the Linux package are unaffected. ### OAuth ROPC Grant Removed - The Resource Owner Password Credentials OAuth flow will be removed across GitLab.com, Self-Managed, and Dedicated. - ROPC is being eliminated because of security limitations and its removal from OAuth 2.1. - Applications using ROPC must migrate to a supported flow, such as Authorization Code. - After upgrading, ROPC will not work even when client credentials are provided. ### PostgreSQL 17 Becomes Required - PostgreSQL 16 will no longer be supported; PostgreSQL 17 becomes the minimum version. - Single PostgreSQL instances installed through the Linux package may be upgraded automatically during GitLab 18.11. - Cluster deployments and installations that opt out of automatic upgrades require a manual migration. - Administrators should verify sufficient disk space and complete the upgrade before GitLab 19.0. ## Medium-Impact Changes ### Ubuntu 20.04 Packages Discontinued - GitLab will stop publishing Linux packages for Ubuntu 20.04. - GitLab 18.11 is the final release supporting that distribution. - Affected installations must upgrade to Ubuntu 22.04 or another supported operating system first. ### Redis 6 Support Removed - External Redis 6 deployments must migrate to Redis 7.2 or Valkey 7.2. - The Linux package’s bundled Redis is unaffected because it has used Redis 7 since GitLab 16.2. - Migration options vary by provider: - AWS ElastiCache and GCP Memorystore: Redis 7.2 or Valkey 7.2. - Azure: self-host Redis or Valkey on VMs or AKS until managed support is available. - Self-hosted installations: upgrade directly to Redis 7.2 or Valkey 7.2. ### Auto DevOps Builder Image Updated - The CNB builder image used by Auto DevOps changes from `heroku/builder:22` to `heroku/builder:24`. - Pipelines relying on the older image may need testing or configuration updates. GitLab administrators should review the deprecations and upgrade documentation, identify whether their deployment uses any affected components, and complete required migrations before GitLab 19.0.

gitlab

5 ways GitLab pipeline logic solves engineering problems (opens in new tab)

GitLab’s pipeline model addresses complex CI/CD needs by combining composable features rather than relying on a single linear workflow. Parent-child pipelines, DAG execution, and multi-project triggers help teams scale monorepos and coordinate services across repositories while preserving clear ownership and failure visibility. The article argues that these patterns make pipelines both faster and easier to maintain. ## Monorepos: Parent-child pipelines and DAG execution - A monorepo containing frontend, backend, and documentation projects should not rebuild everything for every change. - Parent pipelines can trigger child pipelines for individual services using `trigger: include`. - Multiple included files are merged into one child pipeline, allowing jobs across files to share context and reference one another with `needs:`. - `strategy: depend` makes the parent wait for child pipelines and report one overall success or failure while retaining detailed drill-down. - Each service can own its pipeline configuration, reducing the risk that changes in one service break another. - DAG execution with `needs:` allows dependent jobs to start as soon as their prerequisites finish instead of waiting for an entire stage. - For example, API tests can begin immediately after the API build completes, without waiting for unrelated jobs. ## Microservices: Cross-repository pipelines - When frontend and backend services live in separate repositories, independent pipelines may miss integration failures. - GitLab multi-project pipelines allow one repository to trigger and await a pipeline in another project. - The frontend can generate an API contract artifact, publish it, and trigger the backend pipeline with `strategy: depend`. - The backend downloads the artifact through the GitLab Jobs API using `CI_JOB_TOKEN`. - An integration test can reject breaking API changes and propagate the failure back to the frontend pipeline. - The backend job uses `CI_PIPELINE_SOURCE == "pipeline"` so the contract validation runs only when initiated by the frontend, not during ordinary backend pushes. - The frontend project identifier is supplied through a CI/CD variable such as `FRONTEND_PROJECT_ID`. These patterns let teams reduce unnecessary work, preserve service-level ownership, and make cross-service compatibility checks part of the delivery process.

gitlab

10 AI prompts to speed your team’s software delivery (opens in new tab)

AI-assisted coding can accelerate code production without accelerating delivery, because review, security, documentation, and planning often become the new bottlenecks. The post recommends applying AI across the full software lifecycle, using targeted prompts to reduce routine work and let teams focus on architecture, risk, and business decisions. ## Code Review as an Accelerator - AI can review merge requests (MRs) for: - Logical errors, edge cases, and potential bugs. - API changes, altered return types, schema modifications, and configuration changes that may break consumers. - Catching these issues before human review reduces repeated review cycles and helps prevent deployment-time rollbacks. ## Shifting Security Left - Security scan analysis can use AI to: - Distinguish real vulnerabilities from false positives. - Explain risks and recommend remediation. - Prioritize findings by severity and exploitability. - AI-assisted code reviews can identify injection flaws, authorization problems, data exposure, insecure dependencies, and cryptographic weaknesses before an MR is created. - This reduces security-team backlogs and limits late-stage developer/security rework. ## Keeping Documentation Current - AI can generate release notes from merged MRs, organizing changes into features, fixes, performance improvements, breaking changes, and deprecations. - It can also identify which README files, API references, architecture diagrams, and onboarding guides need updates after code changes. - Automating these checks helps prevent documentation drift without creating a separate manual task. ## Breaking Down Complex Planning - An AI planning prompt can decompose an epic into implementable issues by considering: - Technical dependencies. - Appropriate issue sizes. - Acceptance criteria. - Implementation order. - The goal is to replace lengthy planning meetings with an initial AI-generated breakdown followed by team review. The practical recommendation is to treat AI as a team workflow accelerator, not merely a code generator. Applying focused prompts to review, security, documentation, and planning can help prevent increased coding speed from creating larger downstream bottlenecks.

gitlab

AI can detect vulnerabilities, but who governs risk? (opens in new tab)

AI can increasingly detect vulnerabilities and suggest fixes, but detection alone does not make software secure. The post argues that enterprises also need governance, context, continuous assurance, and supply-chain oversight to determine which risks are acceptable and what can ship. GitLab presents its platform as the orchestration layer for enforcing these controls across AI-assisted development. ## Trust Requires Governance - AI analysis is not the same as accountability. - Humans must define acceptable risk, policies, guardrails, separation of duties, and audit requirements. - As autonomous agents gain more control over development, stronger governance becomes essential rather than optional. - Governance enables organizations to trust AI at scale without relying on unchecked autonomy. ## Context Matters Beyond Code Scanning - LLMs typically assess code in isolation, while enterprise platforms can evaluate its broader context. - Important factors include: - Who authored the change - The application’s business criticality - Its dependencies and infrastructure interactions - Whether vulnerable code is reachable in production - Whether the vulnerability is exploitable in the actual runtime environment - Context reduces noisy alerts and supports faster, more effective risk triage. ## Risk Changes Continuously - Dependencies, environments, and system interactions evolve after an initial scan. - A clean static scan does not guarantee that software remains safe at release time. - Organizations need continuous assurance embedded throughout development, testing, and deployment. - Detection identifies risk, while ongoing governance determines how that risk is managed. ## Governing AI-Generated Software - Modern software combines AI-generated code, open-source libraries, and third-party dependencies across many projects. - Governing this entire supply chain is more difficult than detecting flaws in individual code changes. - The post argues that developer-side AI tools alone are not designed to provide organization-wide enforcement and auditability. - GitLab Ultimate is positioned as a platform combining policy enforcement, security scanning, governance, and auditing within software delivery workflows. Organizations adopting AI most successfully will pair capable coding assistants with strong, continuous governance. The practical recommendation is to treat AI security as a platform and lifecycle-management problem—not merely a vulnerability-detection problem.

gitlab

GitLab Duo Agent Platform with Claude accelerates development (opens in new tab)

GitLab Duo Agent Platform integrates external AI models such as Anthropic’s Claude and OpenAI’s Codex directly into GitLab workflows. Instead of operating as isolated coding assistants, these agents use project context and organizational standards to handle multi-step development tasks. The result is faster delivery, more consistent quality, and less manual work across the software development lifecycle. ## From an Idea to a Working Application - An agent can use an issue’s title and detailed requirements as the foundation for a complete application. - It analyzes project context and related assets, then generates: - Backend Java classes - Frontend HTML, CSS, and JavaScript - Business logic and UI components - Build configuration - The agent creates a merge request containing the implementation for developers to test and refine through natural-language interaction. ## Automated Code Review - Developers can mention the external agent in a merge request to request a review. - The review can cover: - Code strengths and critical issues - Medium- and low-priority improvements - Security risks - Testing gaps and code metrics - Recommendations and an approval status - This provides consistent review coverage while allowing senior developers to focus on architecture and complex decisions. ## Pipeline and Container Image Creation - When a project lacks CI/CD configuration, the agent can generate the required pipeline. - It creates a Dockerfile with a suitable base image for the project’s Java version. - The pipeline can: - Build the application - Build a Docker image - Push the image to GitLab’s container registry - The resulting workflow runs automatically through build, image creation, and deployment stages. ## Broader Impact on Development - External agents remain within GitLab, reducing context switching between development tools. - They can follow project-specific coding standards and understand broader repository context. - Teams can automate work from initial requirements through implementation, review, and deployment. - Developers spend less time on repetitive tasks while maintaining stronger consistency and quality. GitLab presents Duo Agent Platform as a way to turn external AI models into integrated development collaborators. Teams can use it to accelerate coding, automate reviews, and create deployment pipelines while keeping humans focused on validation, architecture, and innovation.

gitlab

GitLab metrics and registry features help reduce CI/CD bottlenecks (opens in new tab)

GitLab’s two new beta features target common CI/CD bottlenecks without requiring additional third-party tools. CI/CD Job Performance Metrics provides job-level visibility into duration and failures, while Container Virtual Registry centralizes pulls from multiple registries through a cached GitLab endpoint. Together, they help platform teams identify pipeline problems faster and simplify container management. ## CI/CD Job Performance Metrics - Available in GitLab Premium and Ultimate. - Limited beta on GitLab.com; available on Self-Managed and Dedicated with ClickHouse configured. - Adds a job-focused panel to **Analyze > CI/CD analytics**. - Shows, for the previous 30 days by default: - Median (P50) and worst-case (P95) job duration - Failure rate - Job name and pipeline stage - Supports sorting, searching, and pagination to identify slow or unreliable jobs. - GitLab plans to add stage-level aggregation for build, test, and deploy bottlenecks. ## Container Virtual Registry - Available in GitLab Premium and Ultimate; API-ready in GitLab 18.9. - Provides one GitLab endpoint for pulling images from multiple upstream registries. - Supports registries such as Docker Hub, Harbor, Quay, and other sources using long-lived token authentication. - Uses pull-through caching to: - Reduce repeated downloads and bandwidth costs - Improve availability and reliability - Centralize authentication and registry configuration - Currently configured through the API, with UI management in development. - Cloud registries requiring IAM authentication, including Amazon ECR, Google Artifact Registry, and Azure Container Registry, may be supported later. ## Beta Access and Feedback - GitLab.com users can request access through their customer success manager or the feature’s feedback issue. - Self-managed users can enable the feature flag and configure the virtual registry through the API. - GitLab is seeking feedback to guide future improvements to both features. These betas are worth evaluating if your team needs better visibility into pipeline performance or manages images across several registries. The metrics feature can replace custom dashboards, while the virtual registry can reduce registry-related configuration and operational overhead.