标签：#gitlab

The fast fix If your GitLab CI job fails with Cannot connect to the Docker daemon at unix:///var/run/docker.sock , your docker client is looking for a local socket that does not exist inside the job container, because DOCKER_HOST is not set. Point the client at the docker:dind service over TCP and the error goes away: build : image : docker:28.3 services : - name : docker:28.3-dind alias : docker variables : DOCKER_HOST : tcp://docker:2376 DOCKER_TLS_CERTDIR : " /certs" DOCKER_CERT_PATH : " /certs/client" DOCKER_TLS_VERIFY : " 1" script : - docker info - docker build -t my-app . That is the whole fix for the common case. The rest of this page explains why the socket variant of the error is different from the tcp://docker:2375 variant, and covers the two other setups (socket-mounted runners and the Kubernetes executor) where the same message shows up for a different reason. Why you get the unix socket variant specifically This error is not the same as Cannot connect to the Docker daemon at tcp://docker:2375 . The address in the message tells you exactly what the client tried: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? When DOCKER_HOST is empty, the Docker CLI falls back to its compiled-in default, the local unix socket at /var/run/docker.sock . Inside a GitLab CI job that uses the docker executor, that socket file simply is not there. The daemon runs in a separate docker:dind service container, not in your job container, so there is nothing listening on the local socket. The client connects, finds no socket, and prints the message above. The tcp://docker:2375 form is the opposite problem: DOCKER_HOST is set correctly but the dind service is not reachable (missing service, no privileged mode, or a TLS mismatch). If you are seeing that address instead, read the companion write-up on the tcp://docker:2375 form of this error , which walks the service and privileged-mode causes in detail. This page is about the case w

GitLab has introduced a new approach to Green DevOps, demonstrating how software engineering teams can measure the carbon emissions generated by their CI/CD pipelines. By Craig Risi

GitLab has released version 19.2 of its DevSecOps platform, adding agentic automation aimed at the security and review work that has piled up as AI coding tools generate more code than developers can check by hand. The release, announced on 16 July 2026, brings four features out of beta or into public beta: Dependency Scanning Auto-Remediation, Security Review Flow, GitLab Duo CLI and Custom Flows By Matt Saunders

If you work on long-lived feature branches, you've probably experienced this: master (or main ) keeps moving. Your branch falls behind. Pull requests become harder to review. Merge conflicts get bigger every day. Many teams solve this by rebasing their feature branches. Others—including many enterprise teams—prefer merging the latest master into the feature branch to preserve commit history and avoid rewriting commits that may already be shared. If your workflow uses merge instead of rebase, this article shows how to make the process much faster with a custom Git alias. The Problem Imagine your repository looks like this. master A──B──C──D feature/login \ E──F While you're developing, your teammates merge several pull requests. master A──B──C──D──G──H──I feature/login \ E──F Now your feature branch is missing the latest changes. If you don't sync it: merge conflicts accumulate CI may fail unexpectedly testing becomes less reliable your eventual pull request becomes much harder to review Keeping your branch up-to-date regularly makes integration much smoother. Updating Your Branch Manually Suppose you're working on: feature/login and want to sync it with master . First, fetch the latest changes: git fetch origin Switch to your feature branch: git checkout feature/login Reset your local branch to match the remote version: git reset --hard origin/feature/login Why reset? This ensures your local branch exactly matches the remote branch before merging. It's useful if your local branch is only a working copy of the remote branch. Warning: Any unpushed commits will be permanently deleted. Merge the latest master : git merge --no-ff origin/master Finally, push the updated branch: git push Your history now becomes: master A──B──C──D──G──H──I \ feature/login M \ / E──────F where M is the merge commit. That's a Lot of Typing... Every time you want to synchronize a branch, you're repeating the same commands: git fetch git checkout feature/login git reset --hard origin/feature/l

The pipeline died at 5:07 on a Friday I still catch myself alt-tabbing back to the browser every time a pipeline breaks. Terminal, editor, browser, until I have hunted down the failing job and pasted a stack trace somewhere I can actually think about it. GitLab has made that dance a bit shorter. The Duo CLI reached general availability with GitLab 19.2 on July 16, 2026, and the pitch is simple: Duo Agentic Chat, in the shell you were already in. What actually shipped The short version, straight from the announcement: Duo CLI carries the Duo Agent Platform into the terminal, and your sessions travel with you. Start a plan in the CLI, keep it going in the web UI, pick it back up in an editor extension. Same context, same permissions, different surface. That continuity is the piece I care about most, because it stops me from re-explaining the same problem to the same agent three times in one afternoon. There are two shapes to work in. Interactive mode is the conversational one you would expect, with plan and build capabilities for iterating on a change. Headless mode is the one CI teams should look at, because it drops the same agent into a job or a script, no TTY required. Two built-in slash commands worth knowing on day one: /doctor for a setup check and /mcp to inspect the MCP configuration it is wired to. Two ways to install, one auth story The install decision is refreshingly small. If you already run glab , the GitLab CLI, then glab duo cli gets you moving and glab handles authentication for you. If you would rather have the agent as its own binary, you can install duo standalone and hand it a personal access token. Both paths reach the same tool. Both work on GitLab.com, Self-Managed and Dedicated, and admins get an instance-level toggle to switch access on or off for their org. The gating detail your finance-adjacent brain will want: you need Premium or Ultimate with the Duo Agent Platform turned on, and usage draws from the GitLab Credits already included with

AI coding tools are incredible. But I noticed something — they ship code fast, skip the rules, and nobody catches it until it's already in production. That's exactly what GuardDuo is built to fix. The Problem We're in the age of vibe-coding. You describe what you want, the AI builds it, it works — and you ship it. But "works" and "correct" are two very different things. Imagine asking an AI to build a login form. It works perfectly. But under the hood it has hardcoded API keys, no input validation, missing aria-labels , and it's using fetch directly instead of your project's apiClient wrapper. Your Issue said none of that was allowed. Nobody caught it. That's the vibe-coding trap — and it's happening on every team using AI-assisted development right now. What is GuardDuo GuardDuo is a GitLab Duo Agent skill that acts as your AI guardian. Instead of just reviewing code in isolation, it cross-references your code changes against the actual intent of the linked GitLab Issue — using the Orbit Knowledge Graph , which is essentially the brain that knows your project's rules, requirements, and success criteria. In plain terms: GuardDuo reads what the Issue asked for , reads what the code actually does , and tells you exactly where they don't match. It audits across three dimensions: 🔐 Security — hardcoded secrets, SQL injection, missing input validation ♿ Accessibility — missing alt text, aria-labels , poor color contrast 📐 Standards — deviations from your project's established patterns and conventions And when it finds a problem, it doesn't just flag it — it fixes it. How It Works Just open GitLab Duo Chat or GitLab Agent Platform(on your choice of IDE) -> choose the agent as GuardDuo and type: Audit issue #[issue no.] — GuardDuo pulls the Issue context from Orbit, analyzes the code, and returns a structured report Fix issue #[issue no.] — GuardDuo generates a corrected implementation that satisfies all requirements Or paste any code snippet directly and ask it to audit o

Parent/child first. Evidence emission second. Ansible control plane third. Every release was a manual evidence collection exercise. The pipeline was the bottleneck. This is a redacted write-up of a real engagement: rebuilding a healthcare SaaS company's CI/CD pipeline across a fleet of Linux hosts on AWS. The context The engineering team had grown faster than the pipeline architecture had evolved. What started as a single-stage GitLab job for a small team had been extended, patched, and worked around as the team scaled past the patterns the original pipeline was built for. The result was familiar. Each deploy took 30 to 45 minutes of mostly-serial execution. Engineers had developed informal habits to work around the slowness, including pushing partial changes outside the pipeline when the timeline got tight. Audit windows were preceded by three-week sprints in which the team manually compiled deployment logs, screenshots of access reviews, and approval chains into PDFs describing what the pipeline was supposed to be doing. The work was technically passing HIPAA audits, but the audit was a snapshot of a system the auditor could not independently verify. The cost was paid twice: the velocity loss on every deploy, and the three-week scramble before each assessment. The team knew the architecture was wrong. They needed engineering hands to redesign it without slowing the product roadmap the audits were already eating into. The approach The redesign moved in three layers. First, decompose the monolithic pipeline into parent/child stages so work can parallelize and the audit boundary of each stage is provable. Second, build structured evidence emission into every stage as a property of how it runs, not an after-the-fact compilation task. Third, layer an Ansible control plane across the host fleet so HIPAA control state is continuously validated, not reviewed quarterly. ┌────────────────────────── Parent Pipeline (.gitlab-ci.yml) ──────────────────────────┐ │ │ │ ┌────────

The company is reducing its workforce as it exits 22 countries, reduces management layers, and invests in its infrastructure to scale its platform.