GitLab CI and Distributed Builds

7/22/2026

This post details the integration of Cursor, an AI coding agent, with GitLab's Duo Agent Platform and Model Context Protocol (MCP) to facilitate the modernization of Java applications. It outlines a three-use-case tutorial: fixing a failing Java end-to-end test with Cursor, preparing quality gates for Java 8 to 21 modernization by leveraging GitLab's epic and issue hierarchy with MCP to bring context into Cursor, and modernizing HTTP connection handling with Java 21. The post emphasizes the importance of CI/CD, security scanning, code review, and impact analysis in ensuring the safety of AI-generated code changes during complex migrations.

7/9/2026

Introduced integrations with Eco CI and Carmen to measure and report on carbon emissions within GitLab CI/CD pipelines. Eco CI provides per-job emission data, while Carmen offers infrastructure-level insights into operational and embodied carbon. Provided examples of how to integrate these tools into `.gitlab-ci.yml` and discussed practical use cases for identifying and reducing carbon waste in pipelines and infrastructure.

5/21/2026

Introduced Components Analytics view in the CI/CD Catalog, providing visibility into the usage of standardized pipeline components across an organization. This includes a high-level adoption view (available in all tiers) showing usage counts and latest versions, and a detailed drill-down view (available in Ultimate) showing specific projects using specific versions, identifying outdated versions, and enabling targeted actions for security and maintenance. This addresses the visibility gap in shared CI, allowing for better governance, auditing, and management of reusable pipeline components, especially in the context of AI-generated pipelines.

4/9/2026

This post details five specific engineering problems solved by GitLab's advanced CI/CD pipeline execution model: monorepos (parent-child pipelines + DAG execution), microservices (cross-repo, multi-project pipelines), multi-tenant/matrix deployments (dynamic child pipelines), and MR-first delivery (merge request pipelines, merged results, and workflow routing). It provides concrete configuration examples and explains the technical benefits of each pattern, such as reduced pipeline runtime, improved cross-service breakage detection, manageable deployment matrices, and testing what will actually land on main.

4/7/2026

This post details how GitLab's Pipeline Execution Policies (PEPs) can be used to address recent supply chain attacks targeting CI/CD pipelines. It explains three attack patterns: poisoned tools/actions, packaging misconfigurations, and vulnerabilities in transitive dependencies. It then introduces specific PEPs like 'Artifact Hygiene' and 'Dependency Integrity' as solutions, demonstrating how they inject mandatory jobs into pipelines to validate package contents, check for malicious files, enforce package size limits, and compare dependency checksums against known-good states. The post also highlights the open-source 'Supply Chain Policies' project for ready-to-use PEPs.

2/26/2026

This post details the integration of GitLab CI/CD pipelines with Google Cloud's Agent Engine for deploying AI agents. It covers configuring IAM using Workload Identity Federation for secure, keyless authentication, setting up a `.gitlab-ci.yml` file with pre-defined security scanning templates (dependency scanning, SAST, secret detection), and utilizing the Google Agent Development Kit (ADK) CLI for the actual deployment. The post also outlines how to test the deployed agent using `curl` and highlights the security benefits of this approach, such as eliminating long-lived credentials and providing a complete audit trail.

11/10/2025

This post details the integration of GitLab CI/CD with Google Cloud's GKE for secure deployment of AI agents. It outlines the steps for configuring IAM and Artifact Registry integrations within GitLab, and provides a complete `.gitlab-ci.yml` file that includes stages for building Docker images, running security scans (dependency, container, secret detection), uploading to Google Artifact Registry, and deploying to GKE using Kubernetes manifests. It also includes a bash script for setting up the necessary GCP Service Account, IAM roles, and Kubernetes Service Account with Workload Identity Federation for secure access to Vertex AI.

11/4/2025

This post introduces and advocates for the use of pipeline inputs as a more secure and robust alternative to pipeline variables for customizing GitLab CI/CD pipelines. It details the benefits of pipeline inputs (explicit declaration, type safety, validation, security) and provides guidance on how to migrate by restricting pipeline variables and converting existing variables to inputs. It also covers migrating trigger jobs and offers a summary of the security enhancements.

10/16/2025

This post details how to share variables and artifacts between parent and child GitLab CI/CD pipelines. It introduces the use of `dotenv` reports to save runtime variables and leverage the `needs` keyword (for Premium/Ultimate users) to inherit these variables and artifacts in child pipelines. It also covers triggering child pipelines based on file changes using `rules: changes` and provides examples for sharing custom variables like Docker image tags.

10/10/2025

This post details the GitLab Data team's creation of a structured Streamlit Application Framework within Snowflake. It leverages GitLab CI/CD for automated testing, code review, and deployment of Streamlit applications. The framework establishes clear roles (Maintainers, Creators, Viewers), enforces security and compliance through automated checks and templates (e.g., class rules, file rules, share rules), and streamlines development with features like one-click environment preparation, template-based page creation, and Poetry-based dependency management. The architecture emphasizes structure, governance, and automation for scalable and secure data application development.

10/2/2025

Introduces 'managed lifecycle environments' for virtual testing in embedded systems development. This feature ties virtual testing setups to merge requests, automating provisioning and cleanup to avoid environment sprawl and rebuild costs. It supports various virtual testing types like MIL and SIL, persisting environments throughout feature development and automatically cleaning them up upon merge.

9/15/2025

This post details the implementation of GraphQL subscriptions over WebSockets to replace polling for GitLab CI job status updates. This significantly reduced API calls by 92.56% (from 45 million to 3.4 million per day) and provides instant status changes to users, improving the user experience and reducing database load. The transformation involved refactoring the job header component to use GraphQL and implementing subscriptions with ActionCable.

9/2/2025

This post details how GitLab CI/CD can be leveraged for secure Rust development. It provides concrete examples of `.gitlab-ci.yml` configurations for building Rust applications across multiple platforms (Linux, Windows, macOS) using cross-compilation. It also demonstrates setting up automated testing, including unit tests, integration tests, and code quality checks (Clippy, formatting). Furthermore, it showcases publishing Rust applications as generic artifacts to the GitLab Package Registry and containerizing them for the GitLab Container Registry. The post highlights the benefits of GitLab's caching mechanisms for Rust's compilation times and its integrated DevSecOps approach.

7/7/2025

This post introduces and details GitLab CI/CD inputs as a secure and preferred method for passing parameters to pipelines. It highlights the limitations and risks of using CI/CD variables for this purpose, such as lack of type validation, runtime mutability, and security concerns. The post explains how inputs provide type safety, validation at pipeline creation time, and flexibility in interpolation, enabling unique job naming and reducing maintenance overhead through reusable templates. It contrasts variable-based approaches with input-based solutions using code examples.

7/1/2025

This post introduces the concept of 'embedded DevSecOps' and highlights how GitLab's CI/CD capabilities, particularly the On-Premises Device Cloud component, enable continuous testing for embedded systems. It emphasizes the shift from hardware bottlenecks to automated testing, including SIL and HIL testing within CI pipelines, and the standardization of builds with version-controlled environments. The post also details the automation of compliance and security governance through automated compliance frameworks and the integration of specialized tools into CI pipelines, enabling faster bug fixes and deployments. Finally, it discusses enabling collaborative innovation through shared code visibility and integrated CI/CD workflows.

6/23/2025

This post introduces GitLab Ultimate for IBM Z, which extends GitLab's CI/CD capabilities to the mainframe environment with native z/OS Runner support. It enables CI/CD pipelines to run directly on IBM z/OS, modernizes source code management by replacing legacy library managers with GitLab's repository system, and integrates with IBM Developer for z/OS Enterprise Edition for enhanced debugging and code scanning. This allows for unified development workflows across mainframe and distributed systems.

6/5/2025

This post introduces and details the use of GitLab's CI/CD capabilities, specifically the On-Premises Device Cloud CI/CD component, to address challenges in embedded development. It explains how to automate hardware allocation and testing for Hardware-in-the-loop (HIL), Software-in-the-loop (SIL), and Processor-in-the-loop (PIL) within GitLab CI pipelines. It also highlights the use of containerization and standardized build automation for consistent build environments and discusses how a unified platform like GitLab can break down silos in embedded development.

5/27/2025

This post details the functionality, importance, and scoping of CI/CD variables within GitLab. It explains how to define and use project-level, group-level, and instance-level variables, emphasizing their role in flexibility, security, and maintainability. It also covers best practices for managing sensitive information and leveraging predefined variables.

4/25/2025

This post introduces the fundamental concepts of CI/CD, explaining Continuous Integration, Continuous Delivery, and Continuous Deployment. It details the core elements of GitLab CI/CD: the .gitlab-ci.yml file, GitLab Runner, stages, and jobs. It provides basic and more realistic configuration examples for building and deploying Node.js applications, and deploying to staging and production environments with manual approval. It also introduces GitLab Auto DevOps for simplified setup and highlights the CI/CD Catalog and CI templates for extending and standardizing CI/CD workflows.

3/25/2025

This post details a tutorial for securely publishing BigQuery data using GitLab CI/CD. It outlines the architecture involving version-controlled SQL, automated authentication with Google Cloud (service accounts or Workload Identity Federation), BigQuery query execution, export to CSV, and upload to Google Cloud Storage with public read ACLs. It also provides specific steps for configuring GitLab CI/CD variables and the `.gitlab-ci.yml` file.

1/29/2025

This post details the implementation of a Detections as Code (DaC) pipeline using GitLab CI/CD to automate the creation, testing, and deployment of SIEM threat detections. Key contributions include: defining a JSON format for detections, establishing a merge request workflow for changes, implementing automated CI/CD jobs for validation (query format, JSON fields, SIEM API checks), enforcing peer review via merge request approval rules, and automating the final deployment to the SIEM and updating MITRE ATT&CK mapping. A sample `gitlab-ci.yml` and a Mermaid diagram illustrate the workflow.

1/28/2025

This post details the integration of GitLab CI/CD with Google Cloud to enable developers to deploy Go applications to Google Cloud Run. It outlines the steps for creating a GitLab project, developing a Go server, using the Google Cloud integration to create a service account and configure Cloud Run via a merge request, and accessing the deployed server. The post also provides code snippets for the Go server and instructions for cleaning up the environment.

1/23/2025

Introduces hosted runners for GitLab Dedicated, offering managed CI/CD infrastructure with reduced operational overhead, automatic scaling, cost optimization, and enterprise-grade security. Adds native Arm64 support alongside x86-64, enabling native builds for Arm-based applications and multi-architecture container image creation. Details available runner sizes (Small, Medium, Large, X-Large, 2X-Large) with vCPU, memory, and storage specifications. Outlines future plans including general availability in May 2025 with compute minute visualization, and subsequent additions of network controls, macOS runners, and Windows runners.

1/15/2025

This post details the integration of GitLab CI/CD with Google Cloud's Workload Identity Federation, Artifact Registry, and Cloud Run. It provides step-by-step instructions for configuring these services, including setting up IAM policies, creating Artifact Registry repositories, and defining `.gitlab-ci.yaml` to build Docker images, push them to Artifact Registry, and deploy them to Cloud Run. The post also includes example `.gitlab-ci.yaml` configurations and highlights the security benefits of using Workload Identity Federation.

1/13/2025

This post details the integration of GitLab CI with Google Cloud Run for deploying NodeJS Express applications. It introduces a specific CI template (`cloud-run.gitlab-ci.yml`) that automates the creation of a service account, configuration of Cloud Run via a merge request, and deployment. The post outlines the steps for setting up a project, including the necessary CI template, and demonstrates the successful deployment and verification of the application.

12/10/2024

This post details the process of deploying a PHP application to Google Cloud Run using GitLab CI. It covers creating a new GitLab project, setting up a basic PHP application, utilizing GitLab's Google Cloud integration to create a service account and configure Cloud Run via a merge request, and adding new endpoints to the deployed application. It also provides instructions for cleaning up resources to avoid charges.

11/19/2024

This post details how to provision group runners on GitLab.com using Google Cloud Platform and Terraform. It covers creating a new group runner, configuring its tags and description, registering it with GCP, and provisioning the infrastructure using `gcloud cli` and Terraform. It also includes a sample `.gitlab-ci.yml` to demonstrate picking up the first job.

11/4/2024

This post details the technical steps for deploying a Python Flask server to Google Cloud Run using GitLab CI. It covers creating a GitLab project, setting up a Flask application with `main.py` and `requirements.txt`, configuring a Google Cloud service account and region through GitLab's integration, and automating the Cloud Run deployment via a merge request. It also shows how to access the deployed service and provides instructions for cleaning up the environment.

10/16/2024

Introduces CI/CD Steps as a mechanism to allow CI/CD components to access and execute additional files (scripts, dependencies) stored within the same repository as the `step.yml` definition. Details the `run` keyword for components to execute steps and the `${{ step_dir }}` expression for referencing files within the step's cached repository. Highlights the difference between components (pipeline creation phase) and steps (job execution phase).

9/26/2024

This post introduces a strategy for continuous deployment across multiple environments (review, integration, QA, staging, production) using child pipelines and Terraform. It details how to manage infrastructure as code (IaC) with Terraform, leveraging GitLab's CI/CD for automated deployments to these environments, including temporary review environments that are automatically destroyed. The workflow emphasizes testing, security, and controlled progression from development to production.

9/12/2024

This post details the development of 'Runway', an internal platform built on GitLab features, to provision, deploy, and operate multi-region containerized services. It highlights the use of GitLab CI/CD, environments, deployments, Terraform, OpenID Connect with GCP Workload Identity Federation, Projects API, CI/CD variables, Job Token allowlist, Pages for schema documentation, CI/CD templates, Releases, Container Registry, Trigger Pipelines, and Multi-Project Pipelines. The platform enables self-service infrastructure for service owners, focusing on low-latency AI features by leveraging multi-region deployments with global load balancing and regional resource provisioning.

8/27/2024

This post details Indeed's successful migration from Jenkins to GitLab CI. It outlines the technical challenges faced with Jenkins' architecture (single point of failure controllers, manual scaling) and the problems with their previous Groovy Jenkins DSL approach (job duplication, maintenance burden). The post explains the adoption of GitLab CI, highlighting its scalability, cloud-native design, and template extensibility which aligned with their 'golden path' strategy. It describes the migration process, including creating golden path templates for common project types (Java, Python, JavaScript), leveraging InnerSource for contributions to these templates, and employing strategies like 'scream tests' and controller read-only policies to drive adoption. The benefits realized, such as increased pipeline volume, reduced hardware costs, and decreased support burden, are quantified.

8/6/2024

Introduces CI/CD Steps, a new programming language for DevSecOps automation, designed to create more complex and reusable automation workflows beyond traditional YAML. This experimental feature aims to address limitations encountered at enterprise scale and offers a "post-YAML" approach to pipeline authoring. It allows for composable pieces of CI jobs, enabling developers to define inputs and outputs for steps, similar to functions in modern programming languages. The feature is currently in an experimental phase with a beta release targeted for late 2024.

8/1/2024

This post is an FAQ that clarifies and expands upon the capabilities of the GitLab CI/CD Catalog. It addresses questions regarding component versioning (supporting branches and tags), the creation of composite components, various testing strategies (commit-based, child pipelines), referencing branches as versions, populating self-managed catalogs, mirroring components, preventing job name collisions using inputs, inspecting component source code, supporting array inputs, limitations compared to CI Steps, best practices, roadmap items for private components and group-specific component usage, the relationship between CI Steps and components, managing forks, creator verification processes, recommendations for integrating external tools like Fortify SCA, the roadmap for component outputs (CI Steps), plans for component labeling and discoverability, the migration of existing CI/CD templates to components, and recommended approaches for transitioning from existing templates to catalog components.

7/30/2024

Introduced a new approach for monorepo CI/CD pipelines in GitLab 16.4 using `include` with `rules:changes`. This allows for conditional inclusion of pipeline YAML files based on directory changes, simplifying configurations and reducing redundancy compared to the legacy approach of extending hidden jobs. Also highlighted a caveat regarding the `changes` rule behavior with new branches/tags.

7/25/2024

This post provides a foundational overview of Kubernetes, explaining its core concepts such as clusters, nodes, pods, services, volumes, and namespaces. It details the master and worker node architectures, including components like the API server, etcd, controller manager, scheduler, kubelet, and kube-proxy. The role of Docker as a container runtime is clarified, and the distinction between Docker and Kubernetes is explained. The benefits of Kubernetes, including automation, flexibility, scalability, and update management, are discussed, alongside its limitations such as complexity and resource requirements. The post also touches upon the integration of Kubernetes with Git and GitLab, and briefly mentions competing solutions and how to get started.

7/2/2024

This post introduces the integration of Catch2 for C++ unit testing within GitLab CI. It provides a detailed walkthrough of setting up Catch2 as a Git submodule, structuring the C++ project into separate header and source files for better testability, and configuring CMakeLists.txt to build both the application and its tests. It also demonstrates how to write basic tests using Catch2 macros and assertions, and outlines the steps for creating a `.gitlab-ci.yml` file to automate the build and test process.

6/20/2024

Introduced the GitLab agent for Kubernetes (agentk and KAS) to provide a secure bidirectional connection for frontend access to cluster data. Implemented user access rights for secure frontend-to-cluster communication. Developed the `@gitlab/cluster-client` JavaScript library for frontend integration. Enhanced real-time updates with the Watch API and evolved to WebSocket aggregation for improved reliability and reduced overhead when monitoring Kubernetes resources.

6/4/2024

This post details the author's personal journey and best practices in building and publishing GitLab CI/CD components. It introduces the concept of independent component versions, global visibility with control, and catalog metadata. It provides code examples for various components, including 'Hello World', 'Hello World Container', 'GitVersion Ultimate Auto Semversioning', 'Amazon CodeGuru Secure SAST Scanner', 'Checkov IaC SAST', 'Super-Linter', 'Kaniko', and 'CI Component Publishing Utilities'. It also offers guidance on starting new components and finding published components.

5/8/2024

This post announces the General Availability of the CI/CD Catalog, detailing its core features: components (template-type and upcoming CI Steps) and inputs interpolation. It explains how to access and use components, distinguishing between public and private components, and outlining differences between GitLab.com and self-managed deployments. Future plans include CI Steps becoming first-class catalog objects, enhanced security for catalog workflows, and analytics for component usage.

5/6/2024

This post details a new workflow for setting up a remote VS Code development environment on a cloud provider VM (GCP). It involves using Terraform to provision the VM and a separate GitLab CI/CD pipeline to install VS Code and its dependencies. It also outlines the steps for configuring local access via SSH and X11 forwarding, and for cloning GitLab projects into the remote environment.

4/9/2024

This post introduces the public beta of GitLab-Google Cloud integrations. Key technical contributions include: 1. Streamlined authentication using IAM and Workload Identity Federation, replacing service account keys. 2. Introduction of an `identity` keyword in CI/CD YAML for developer-minded authentication. 3. Runner configuration automation for Google Cloud, making hosted runners available without leaving GitLab. 4. A library of Google Cloud Services components in GitLab's CI/CD Catalog for easier deployment to GKE, Artifact Registry, and Cloud Deploy.

3/5/2024

GitLab reaffirms its commitment to FluxCD, a GitOps solution integrated with its agent for Kubernetes. Following the closure of Weaveworks, GitLab will play a more active role in the Flux community and support enterprise customers, collaborating with other partners to ensure the project's stability and continued development.

3/4/2024

This post details the technical steps and considerations for refactoring existing GitLab CI/CD templates into CI/CD components. It outlines the process of creating a component project, copying templates, defining input parameters and metadata using the `spec` keyword, replacing hard-coded values with inputs, and adhering to best practices for components. It also provides code examples of a job in an existing template and its refactored component version, and points to additional resources for further learning.

2/22/2024

This post details how to translate Atlassian Bamboo agent capabilities (executable, JDK, Version Control, Docker, custom) to GitLab Runner tags. It explains how to add tags to GitLab Runners during registration or by editing the `config.toml` file, and how to use these tags in the `.gitlab-ci.yml` file to ensure jobs run on specific runners. It also covers using multiple tags for job targeting and dynamically influencing runner selection using variables and `parallel: matrix` for complex pipeline configurations.

2/8/2024

This post introduces a group-level deploy freeze capability, extending project-level deploy freezes to manage deployment restrictions across multiple projects within a GitLab group via the GitLab UI and CI/CD automation. This is achieved through a Python script that leverages the GitLab API to set and manage freeze periods, ensuring code stability during critical periods.

2/5/2024

Carrefour and Thales are migrating from heterogeneous CI/CD environments (Bitbucket, Jenkins) to GitLab. Carrefour aims for full automation in build, test, releases, versioning, and deployment, including canary deployments and feature flags. Thales emphasizes developer autonomy and shared runners for development environments, and uses SAST, DAST, and secret detection.

1/31/2024

Introduces Hosted Runners for GitLab Dedicated in Beta, providing fully managed, Linux-based, auto-scaling runners with complete tenant isolation for CI/CD jobs on GitLab Dedicated. This extends the flexibility, efficiency, and control of GitLab Dedicated to the runner infrastructure.

1/31/2024

This post details the process of setting up a GKE cluster with ArgoCD pre-installed using a GitLab Terraform template. It covers configuring GCP credentials in GitLab CI/CD variables, running the CI pipeline to deploy the cluster, connecting to the GKE cluster, retrieving the ArgoCD initial admin secret, and port-forwarding ArgoCD to localhost for access. It also provides next steps for integrating with Review Ops.

1/22/2024

Introduced support for Windows 2022 on GitLab SaaS runners, currently in Beta. This is a step towards general availability for SaaS runners. Windows 2019 and its associated tags (`shared-windows`, `windows-1809`) will be deprecated with GitLab 17.0. The new tag for Windows 2022 runners is `saas-windows-medium-amd64`.

1/10/2024

This post introduces the use of Pulumi, an Infrastructure as Code (IaC) tool, to manage GitLab resources, specifically focusing on automating GitLab CI/CD pipelines. It details how to use Pulumi with programming languages like TypeScript, Python, and Go to define and manage GitLab projects, variables, and hooks. The post also covers the integration of Pulumi with AWS for OIDC connectivity, allowing GitLab CI/CD to request temporary AWS credentials. Additionally, it describes setting up a Pulumi project hook for real-time feedback on merge requests.

1/3/2024

This post introduces the concept of 'CI/CD hyperscale' as a response to the increased CI/CD job volume expected with AI-powered DevSecOps. It hypothesizes a 2x increase in CI/CD jobs per year due to AI-assisted features. The post outlines strategies for organizations to support this growth, including analyzing existing tooling, consolidating point solutions into a single DevSecOps platform, and leveraging GitLab's scalable CI/CD engine (GitLab CI and GitLab Runner) for both SaaS and self-managed environments. It highlights GitLab's milestone of over 1 billion pipelines run on its SaaS platform as evidence of its scalability.

12/21/2023

Introduces the GitLab CI/CD Catalog (Beta) as a centralized hub for discovering and sharing reusable CI/CD components. Details the process for users to discover and include components in their `.gitlab-ci.yml` files. Outlines a six-step process for developers to create and publish their own CI/CD components, including project setup, component creation with input parameters using the `spec` keyword, documentation, testing, preparing a release job with semantic versioning, and publishing via Git tags.

12/6/2023

Betstudios upgraded from GitLab's free tier to GitLab Premium specifically to enhance their CI/CD capabilities. This upgrade has already led to automation of deployment processes, saving approximately five hours per week per Team Lead. Future plans include exploring CI/CD with Kubernetes and investigating the possibility of consolidating tools like ArgoCD into GitLab's platform.

11/22/2023

This post details new integrations and solutions for using GitLab and AWS together, focusing on source control, CI, and CD. It highlights specific integrations with AWS CodeStar Connections, Amazon CodeGuru, OpenID, Serverless.com Framework, and Terraform. Technical details are provided on secure Terraform development using GitLab security scanning policies and managed DevOps environments, and secure GitLab CD pipelines to AWS with OpenID Federation, OIDC, and JWT. The integration of AWS CodeGuru Security into GitLab merge requests and security dashboards, enabling blocking merges in security policy merge approval rules, is also discussed.

11/14/2023

This post highlights how HackerOne has significantly reduced their CI/CD pipeline times, leading to a 50% increase in merge requests per engineer and a 50% reduction in code release time over two years. This efficiency gain is attributed to optimizing CI/CD pipelines within GitLab, which directly impacts developer productivity and happiness. The post also touches on HackerOne's use of GitLab for security and compliance, including scanning containers for FedRAMP compliance and implementing review/approval workflows for infrastructure changes.

11/7/2023

This post details the user research and design iteration process for improving the GitLab Runner Fleet dashboard. Key contributions include identifying user pain points regarding fleet visibility, job pickup times, and failure monitoring. The post outlines the design proposals, usability testing insights, and subsequent design updates that led to the inclusion of wait time visualizations, a list of top busy runners, and a list of most recent failures in the dashboard. It also mentions an upcoming Early Adopters Program for feedback.

10/26/2023

This post details the technical steps and considerations for migrating from Bamboo CI/CD to GitLab CI/CD. It outlines the differences in organizational structure (Projects/Plans vs. single platform with .gitlab-ci.yml), the concepts of Agents (Bamboo) vs. Runners (GitLab), and the configuration methods (Bamboo Specs vs. .gitlab-ci.yml). Specific conversion guidance is provided for container images, stages, variables, build jobs (tasks vs. script commands), and deployment jobs. It also highlights GitLab's additional features like application security, compliance policies, CI/CD catalog, and package/container registries.

10/4/2023

This post highlights the milestone of 1 billion CI/CD pipelines run on GitLab's SaaS platform. It details advancements in addressing time-to-market pressures through AI features (Code Suggestions, Suggested Reviewers, Vulnerability Summary, Value Stream Forecasting), security integration (SAST, DAST, policy management, compliance dashboards), and developer productivity via platform engineering 'golden paths' (templates, inheritance rules, IaC, remote development). It also outlines upcoming features: CI/CD catalog, customizable roles, AI for self-managed deployments (Duo Chat), and centralized policy management.

10/4/2023

This post details an upcoming upgrade to the operating system (Container-Optimized OS) and Docker Engine (from 19.03.15 to 23.0.5) for GitLab's Linux SaaS runners. It identifies compatibility issues with Docker-in-Docker and Kaniko jobs due to this upgrade and provides specific instructions on how to update job configurations to resolve these issues by using newer versions of `docker:dind` (20.10+) and `gcr.io/kaniko-project/executor` (v1.9.0+).

9/19/2023

This post details how Debian leverages GitLab's CI/CD functionality through a custom tool called Salsa CI to automate package testing before public release. Salsa CI runs multiple jobs, including building packages on various architectures and executing autopkgtest and lintian, to identify regressions and errors, thereby streamlining software development and accelerating package maintenance for over 900 Debian developers.

8/30/2023

This post details the historical evolution of GitLab, starting from a developer collaboration tool to the integration of SCM and CI into a single platform. It highlights the 'disagree, commit, and disagree' principle as a driver for this integration, which was initially met with resistance but ultimately led to the creation of the DevOps Platform category. The post also touches on future aspirations for an 'AllOps' platform encompassing DevSecOps, ModelOps, and DataOps.

8/29/2023

This post details the integration of GitLab CI/CD with Google Cloud, enabling the use of private Google Cloud-powered runners and CI/CD component templates for deployment to Google Cloud resources (GKE, Cloud Run). It also highlights the integration with Google's Artifact Registry for a security data plane, including SLSA-rated provenance, SBOM, and vulnerability impact information gated by Google's Binary Authorization policies.

8/29/2023

This post details how the Manjaro Linux distribution leverages GitLab's CI/CD functionality to manage over 3,000 packages with a core team of 16 developers and a community of 8,000 participants. It highlights the benefits of self-hosting for data sovereignty and control, and how activity feeds and build failure monitoring provide visibility into project operations. The network effect of upstream projects like GNOME and KDE also switching to GitLab is noted as a benefit for observing ecosystem developments.

8/21/2023

This post details the integration of GitLab Auto DevOps with Google Cloud Run for deploying containerized applications. It outlines the steps for configuring Google Cloud credentials, setting up Auto DevOps in a GitLab project, defining environment variables, and modifying the CI/CD pipeline to include Google Cloud SDK commands for building and deploying to Cloud Run. It also covers the integration of the DAST stage for security testing.

8/15/2023

This post details the deprecation of older tags (`docker`, `linux`) for the small Linux SaaS runner in favor of a consistent tag (`saas-linux-small-amd64`) starting in GitLab 17.0. It explains the impact on jobs using deprecated tags and provides instructions on how to update `.gitlab-ci.yaml` configurations to avoid job failures.

8/1/2023

Introduced medium GitLab SaaS runners on Linux for all tiers, including Free tier users. These runners utilize GCP n2d-standard-4 VMs with 4 vCPUs, 16GB RAM, and 50GB storage, and can be accessed by adding the `saas-linux-medium-amd64` tag in `gitlab-ci.yml`.

7/11/2023

This post details how the Fedora Project migrated its website development workflow to GitLab, leveraging GitLab Pages for automated deployment of static sites and CI/CD for testing merge requests with ephemeral environments. The adoption of GitLab simplified and standardized their development processes, moving away from a fragmented toolchain to a single platform for planning, implementation, and deployment. This initiative aimed to improve contributor experience, reduce burnout, and ensure long-term maintainability of their websites.

7/6/2023

This post introduces a new workflow for automating the creation and registration of GitLab Runners, replacing the legacy runner registration token with access tokens. It details the steps involved: creating an access token (personal, group, or project), using this token to create a runner configuration via the API (e.g., using `curl`), and then automating the installation and registration of the runner application on a target compute host using infrastructure as code (Terraform) and cloud-init scripts. It also highlights the concept of reusable runner configurations for managing fleets at scale and improving UI clarity.

7/5/2023

This post details UI improvements to the pipeline detail page and pipeline list view, including redesigning the pipeline header for better usability and scannability, harmonizing badges and link styles, and linking runner numbers to the runner admin page. Tooltips and button text have also been improved for clarity. The technical implementation involved refactoring the pipeline header from HAML to Vue/GraphQL for better performance and maintainability, and improving the usability of button labels and tooltips.

7/5/2023

This post details the technical steps and configurations required to integrate GitLab CI/CD with Flux CD for GitOps deployments to OpenShift. It covers setting up personal access tokens, creating Git repositories for Flux configuration and application manifests, bootstrapping Flux on OpenShift with specific security context configurations (SCCs) and SeComp profile patches, creating GitRepository resources in OpenShift to sync manifests, and verifying the deployment of an NGINX workload. It also highlights the use of GitLab deploy tokens for secure repository access.

6/27/2023

This post introduces and explains the `rules` feature in GitLab CI/CD, detailing its various keywords (`if`, `changes`, `exists`, `allow_failure`, `variables`, `when`, `needs`) and their practical applications. It demonstrates how to control job execution based on CI/CD variables, file changes, existence of files, and workflow conditions. It also provides use cases for enhancing developer experience and integrating security and quality assurance checks. This post expands on the existing `gitlab-ci-and-distributed-builds` thread by focusing on the conditional execution of jobs within pipelines.

6/14/2023

This post introduces a method for managing multiple infrastructure environments (dev, staging, production) within a single Terraform project using GitLab CI. It details a file structure with environment-specific folders, environment-specific `.gitlab-ci.yml` files that trigger based on file changes within their respective directories, and a shared `helper.yml` for common Terraform jobs (fmt, validate, plan, build, deploy, destroy). It also outlines a merge request workflow for promoting changes through environments.

6/13/2023

This post details the setup of an automated CI/CD pipeline for Android applications using GitLab and fastlane. It covers the installation and initialization of fastlane, the creation and configuration of keystores and properties files for code signing, and the upload of these sensitive files to GitLab's Secure Files. It also outlines the necessary configurations in Gradle and the `.gitlab-ci.yml` file to integrate with the Google Play Console, including creating a Google service account and enabling the integration. The post provides a reference project and specific commands for building and uploading the app.

6/7/2023

This post provides a detailed tutorial on setting up an automated CI/CD pipeline for iOS applications using GitLab and fastlane. It covers prerequisites, installation and initialization of fastlane and fastlane Match, generation of project access tokens and signing certificates, Xcode configuration, Apple App Store integration, and provides sample Fastfile and .gitlab-ci.yml configurations. The tutorial demonstrates how to build and sign iOS apps for development and release to TestFlight.

5/24/2023

This post details the setup of GitLab Runners on AWS EKS Fargate, overcoming limitations of ECS Fargate by leveraging Kubernetes' ability to run any image. It demonstrates the scalability and flexibility of this approach for CI/CD pipelines by using AWS CloudShell, EKS Blueprints with Karpenter autoscaler and Fargate, and a Helm install for GitLab Runner. The results show the ability to run parallel jobs and Auto DevOps pipelines, highlighting the reduced SRE work compared to traditional ECS Fargate.

5/16/2023

This post details how Lockheed Martin, in partnership with AWS, automated and optimized their enterprise-wide code deployment using GitLab's DevSecOps Platform. The solution involved a well-architected review, Infrastructure as Code for rapid deployment, and a highly available, disaster recovery-compliant, scalable architecture. AWS supported load balancing and auto-scaling to manage developer demand for pipeline runs and user traffic, reducing build request backlogs and deployment times. Monitoring and security controls were implemented to comply with Lockheed Martin's policies, showcasing how large enterprises can build and deploy automated, scalable, and resilient code pipelines in the cloud.

5/8/2023

Introduced input parameters for includable CI/CD configuration files, enabling users to define mandatory or optional parameters for templates. This allows for more robust and isolated CI/CD configurations by replacing keywords like stage, script, or job name with parameters. This is the first milestone towards the CI/CD Components Catalog.

5/1/2023

Introduced input parameters for CI/CD templates, allowing explicit definition of mandatory/optional inputs with default values and full CI/CD interpolation support. This enhances template reusability and isolation by preventing variable scope conflicts with upstream includes. This is a precursor to CI/CD components and a component catalog.

3/21/2023

This post details how to use GitLab CI/CD pipelines to automate a Twitter bot. It covers writing a Python script to interact with the Twitter API using tweepy, creating a `.gitlab-ci.yml` file to execute the script, and securely storing Twitter API credentials using CI/CD variables. It also demonstrates how to schedule pipelines to run the bot at regular intervals.

3/8/2023

This post details how GitLab's DevSecOps Platform integrates with Google Cloud's Anthos and Distributed Cloud Edge to enable automated, scalable deployments for retailers. It highlights the use of Agile planning, CI, configuration management (YAML files in repositories), and native Google Cloud integration for managing hybrid and multicloud environments. The post describes a use case for syncing configurations and data across Google Cloud, other clouds, and on-premises environments, and automatically applying new configurations to Google Distributed Cloud Edge nodes across thousands of locations.

2/23/2023

This post details the integration of OctoML CLI into GitLab CI/CD pipelines for machine learning model optimization and deployment. It describes the four pipeline stages (setup, package, deploy, test) and how OctoML CLI accelerates models for various cloud hardware targets, deploying them to registries and managed Kubernetes services. The post also highlights the use of `octoml.yaml` for model configuration and provides example repositories for NLP and Vision models.

2/15/2023

Introduced a reusable GitLab CI shared library extension for code counting using the SCC tool. This extension leverages Git clone optimizations, allows configuration of file extensions to exclude, supports group hierarchy enumeration or specific repo lists, and uploads HTML/text artifacts. It also explores an extension for MR complexity metrics based on diff revision activity.

2/8/2023

GitLab is shifting its recommended GitOps approach from its own agent-based solution to integrating with Flux CD. This involves developing UI integrations for Flux, simplifying its access management to GitLab, and documenting best practices for using Flux with GitLab. The existing agent for Kubernetes GitOps will be moved to maintenance mode.

1/3/2023

This post introduces and details several mechanisms within GitLab for achieving the DRY (Don't Repeat Yourself) principle in development, specifically focusing on CI/CD workflows. It explains and provides examples for `include`, YAML anchors, `extends`, `!reference`, downstream pipelines, and CI/CD variables. Additionally, it covers description templates, project templates, and file templates for standardizing code reviews and project initialization. It also recommends the creation of a "Pipeline Center of Excellence" project for managing reusable CI/CD templates.

12/13/2022

This post announces the change of the default container image for GitLab SaaS Runners on Linux from Ruby 2.5 to Ruby 3.1, effective January 12, 2023. It provides instructions on how users can check their CI/CD jobs for compatibility by configuring them to run in a Ruby 3.1 container. It also mentions plans to define a new container image maintenance process for GitLab SaaS Runners on Linux to ensure the default image is updated with the latest security fixes.

12/8/2022

This post discusses breaking down CI/CD complexity with parent-child and multi-project pipelines, offering a way to streamline CI/CD efforts by choosing the right pipelines for the job.

11/21/2022

This post details how to deploy a Remix application to Cloudflare Workers using GitLab CI/CD. It covers creating a Remix app configured for Cloudflare Workers, setting up a GitLab project, obtaining and configuring a Cloudflare API token as a CI/CD variable in GitLab, and creating a `.gitlab-ci.yml` file to automate the build and deployment process. It also explains how to use a custom domain with Cloudflare Workers.

11/17/2022

This post introduces and details GitLab Review Environments, a feature that automates the lifecycle management of developer environments. It addresses the problems of environment sprawl, cost, and configuration rot by automatically provisioning an environment when a new branch is created and tearing it down when the code is merged. The post highlights how this approach eliminates friction in the development value stream by making environments immutable and isolated on a per-feature branch basis. It also demonstrates extending this capability beyond Kubernetes to other PaaS offerings.

11/15/2022

This post introduces a new approach to managing Kubernetes clusters by combining Terraform for infrastructure provisioning and the GitLab Agent for Kubernetes with Helm for cluster state management. It provides detailed steps for setting up two repositories: one for Terraform-based cluster provisioning (EKS/GKE) and another for cluster management using the GitLab Agent. It also covers cloud credential configuration within GitLab CI/CD variables and the setup of the cluster management project with `helmfile.yaml` for application deployment.

10/25/2022

This post details the migration of GitLab CI artifact downloads from Google Cloud Storage to Google Cloud CDN. This change aims to improve download speeds for CI users by leveraging edge caches. The implementation involves redirecting artifact download requests to `cdn.artifacts.gitlab-static.net` instead of `storage.googleapis.com`, with exceptions for requests originating from within Google Cloud Platform. The post also outlines potential impacts on users with firewalls and provides guidance on troubleshooting common error messages.

10/11/2022

This post introduces the Cloud Seed partnership between GitLab and Google Cloud, which aims to accelerate cloud adoption and app modernization. It details how Cloud Seed can be used to generate Cloud Run deployment pipelines for preview environments, allowing for the deployment of all feature branches to Cloud Run. It also explains how Cloud Seed can be used to spin up and manage relational databases like Postgres, MySQL, and SQL Server with Cloud SQL from the GitLab UI, making them branch, tag, and environment specific.

9/22/2022

Introduced two new machine types for GitLab SaaS Runners on Linux: `saas-linux-medium-amd64` (2 vCPU, 8GB RAM) and `saas-linux-large-amd64` (4 vCPU, 16GB RAM), powered by Google Compute N2D virtual machines. These offer performance improvements for CI workloads, with the medium type showing a 41% reduction in execution time compared to the small type. The post details CI minute consumption cost factors (2x for medium, 3x for large) and provides an example pipeline configuration for selecting these tags.

8/3/2022

Introduces a proof of concept for event-based CI workflows, allowing pipelines to be triggered by platform events via `.gitlab-ci.yml` definitions and hooks into existing webhooks. This extends CI automation to events like issue creation and merge request state changes. Future work includes formal instrumentation and exploration of Platform Events/Cloud Events.

8/2/2022

This post details the integration of Argo CD's ApplicationSet with GitLab's Pull Request generator to provision dynamic review environments. It explains how to configure the ApplicationSet to discover GitLab merge requests and dynamically provision Kubernetes applications using Helm charts. The post outlines the necessary prerequisites, setup steps for GitLab, Kubernetes, and Argo CD, and demonstrates the workflow of creating a merge request, triggering a CI/CD pipeline for building and deploying the application to a review environment, and accessing the deployed application. It also covers the automatic cleanup of these environments when the merge request is closed.

7/28/2022

This post details the outcomes of an internal Hackathon Week focused on improving GitLab's Verify Stage. Key technical contributions include: a POC for easier scrolling through job logs, a POC for adding search and highlight to job logs (merged for 15.3 milestone), a POC for job performance data visualization, a POC for pipeline editor performance insights, a POC for one-click copy of failing test paths (merged), a POC MR for fault-tolerant runner foundation, and an initial concept for GitLab CI workflows. Significant code cleanup was also performed, deleting over 1300 lines of code and 4421 MB of database data.

7/27/2022

This post introduces R2Devops, a platform that creates a collaborative hub of open-source CI/CD jobs. It details how users can link their GitLab account, import their jobs into the R2Devops library, and then use these jobs in their GitLab CI/CD pipelines via the `include` keyword. The post also explains how to customize these jobs using GitLab CI/CD variables and highlights the partnership between R2Devops and GitLab.

7/11/2022

This post details advanced techniques for migrating from Atlassian Bamboo Server to GitLab CI/CD. It covers creating preview environments using GitOps principles, Terraform, and GitLab's infrastructure-as-code capabilities. Specific steps include creating releases, tagging infrastructure blueprints, and deploying applications to newly created environments. The post also outlines how to update an environment's infrastructure by modifying the `version.txt` file in the infrastructure-set repository. It highlights the advantages of this approach, such as keeping familiar concepts and workflows, adhering to GitOps tenets, and empowering user self-service, while also acknowledging shortcomings like the lack of a central aggregated environment dashboard.

7/6/2022

This post details the initial state of a multi-component application's CI/CD setup using Atlassian Bamboo Server, including its build and deployment plans, application architecture, and environment management. It then outlines a proposed migration strategy to GitLab CI/CD, including a suggested GitLab groups/projects structure, and discusses the implementation of environment management using GitLab's Environments feature and Infrastructure as Code (IaC) with Terraform.

6/29/2022

This post details a real-world scenario of scaling GitLab Runner workloads using Kubernetes. It highlights the challenges of resource optimization in a shared CI cluster, where initial attempts to minimize pod resources led to increased developer toil and debugging. The post introduces the concept of tiered runner resource profiles ('large-container', 'xlarge') as a solution to accommodate diverse CI job requirements, and discusses the 'human toil factor' and 'opportunity cost tax' associated with overly granular resource management. It also touches upon the benefits of Kubernetes elastic scaling and the potential for using spot compute for cost savings.

6/9/2022

This post details the steps to automate the software delivery of a generated Quarkus application using GitLab Auto DevOps. It covers generating the Quarkus project via code.quarkus.io, uploading it to a GitLab project, configuring a `DOCKERFILE_PATH` CI/CD variable, modifying the `Dockerfile.jvm` for a multi-stage build, overriding the default application port in `.gitlab/auto-deploy-values.yaml`, setting the `java.runtime.version` in `system.properties` to resolve test compatibility issues, and finally enabling the Auto DevOps pipeline.

6/8/2022

This post introduces the GitLab Agent for Kubernetes as a successor to the previous certificate-based integration. It details the agent's architecture, its GitOps 'pull' mode capabilities, and the installation process using a configuration file and a Docker command. It also highlights the integration with the 'GitLab Cluster Management' template for deploying tools like Prometheus and Sentry, and the CI/CD tunnel feature for direct `kubectl` commands without explicit secret configuration. The post notes that the agent's ability to display pod states on the environment page is a future enhancement.

5/24/2022

This post introduces the concept of 'The Second Law of Complexity Dynamics,' suggesting that complexity is conserved and merely transformed. It argues that using hyper-specialized containers in CI/CD pipelines, while seemingly simplifying dependency management, can shift complexity to the pipeline's YAML and shell scripting, requiring more intricate code and potentially breaking down tasks into multiple jobs. The author proposes a strategy of using more generalized containers (e.g., Bash 5) and performing runtime installs of specific utilities as a way to manage complexity more effectively and avoid efficiency reversals.

5/19/2022

Afnic, the manager of France's .fr domain names, adopted GitLab to modernize its software development environment. They integrated GitLab with Jira and Confluence, and expanded its use beyond developers to database and network administrators. Afnic leveraged GitLab for DevSecOps philosophy and governance, automating and integrating processes during deployment, and utilizing CI/CD capabilities to manage technologies like Kubernetes, Angular, Java, and Docker. This has led to increased automation, cost savings, and developers focusing on higher-value tasks like security and vulnerability compliance.

5/18/2022

Introduces support for pull-based deployment in GitLab's Free tier, utilizing the GitLab agent for Kubernetes to automatically enact application changes. This enhances flexibility, security, scalability, and automation in cloud-native environments by allowing agents within clusters to pull changes, contrasting with push-based deployments that require opening firewalls and granting external CI/CD admin access.

4/14/2022

This post introduces a new workflow for deploying Shopify themes using GitLab CI/CD. It details the setup of Shopify API access tokens as protected CI/CD variables, the creation of a `config.yml` file to map these variables to Shopify themes, and the implementation of a `.gitlab-ci.yml` pipeline with staging and production stages. The pipeline installs the ThemeKit CLI and deploys theme changes based on branch pushes (staging) and tag pushes (production).

4/13/2022

This post provides strategies for getting started quickly with CI/CD, emphasizing developer experience, containerization, starting small, integrating security early, leveraging AI assistance, tailoring tests to common issues, and automating deployments to lower environments. It highlights the importance of fast pipeline runs (under 10 minutes) and integrating status notifications into development tools. It also touches on pre-commit hooks for local checks and the use of static code analysis and dependency scanners.

3/30/2022

This post details how to manage the GitLab agent for Kubernetes itself using GitOps principles. It covers turning an agent installation to manage itself by using kustomize overlays with sealed secrets for authentication tokens, and adopting the agent by the agent using inventory policies. It also outlines how to automate the hydration of manifests using GitLab CI/CD and how to upgrade agentk versions by simply bumping the version number in code.

3/9/2022

Introduces strategies for optimizing GitLab CI pipeline efficiency by focusing on reducing the number of executed jobs and pipelines (using `rules` and `interruptible` keywords) and shortening execution times (through parallel execution with `needs` and `parallel` keywords, parent-child pipelines, failing fast, caching, and optimizing container images). It emphasizes a continuous improvement approach with testing, documentation, and analysis of metrics.

2/22/2022

This post introduces and explains the concepts of parent-child pipelines for managing complexity within a single repository and multi-project pipelines for orchestrating CI/CD across multiple repositories. It details how parent-child pipelines allow for isolated execution of component-specific jobs within a monorepo, while multi-project pipelines enable chaining of independent pipelines from different repositories to form a larger integrated workflow. Key differences in context, control, side-effects, and visibility between the two approaches are highlighted, along with planned future developments for parent-child pipelines.

2/15/2022

This post outlines 10 business benefits of adopting CI/CD, including improved code quality, faster release rates, cost reduction via automation, fault isolation, simplified rollbacks, continuous feedback, transparency, accountability, improved MTTR, and reduction of non-critical defects. It defines CI/CD as a two-step process of automating code integration, version control, testing, and deployment.

2/10/2022

This post demonstrates how to leverage GitLab CI/CD in conjunction with Gitpod to enable coding, building, and deploying applications entirely from an iPad. It details the setup of a `.gitlab-ci.yml` file for deploying to Heroku using `dpl`, including the use of CI/CD variables for authentication. It also highlights the benefits of Gitpod's `.gitpod.yml` for creating consistent, reproducible development environments, significantly reducing onboarding time for new collaborators and enabling a 'cattle, not pets' approach to development machines.

2/8/2022

This post details how to use Auto DevOps with the GitLab Agent for Kubernetes to deploy a minimal application. It outlines the prerequisites, explains Auto DevOps, and provides steps for building a simple Python application with a Dockerfile. The core configuration involves setting up the CI/CD tunnel, defining the Kubernetes context and namespace, and specifying the ingress base domain. Several Auto DevOps features are intentionally disabled to keep the tutorial focused and accessible.

2/1/2022

This post details the implementation of fine-grained permissions for the CI/CD Tunnel using impersonation. It explains how to configure the `access_as` attribute in the Agent's configuration file to impersonate the CI job itself or specific user/system accounts within the Kubernetes cluster. The post provides a step-by-step guide, including setting up a GKE cluster, configuring sample projects, connecting the GitLab Agent, and demonstrating the deployment of an Ingress application using default impersonation and then with `access_as:ci_job`.

1/18/2022

This post introduces the concept of 'as-Code' for various stages of the DevOps lifecycle (Build, Test, Security, Deployment) and highlights how Pipelines-as-Code centralizes these efforts. It emphasizes the benefits of auditability, scalability, efficiency, and collaboration, and mentions using GitLab CI/CD templates and Auto DevOps as examples of implementing Pipelines-as-Code.

1/7/2022

Introduces the 'CI/CD tunnel' feature of the GitLab Kubernetes Agent, which allows GitLab CI/CD jobs to directly access Kubernetes clusters. Details how to configure the agent for CI access, share connections across projects and groups, and use the Cluster Management Project template to deploy applications like NGINX Ingress and GitLab Runners. Demonstrates setting KUBECONFIG environment variables and using `kubectl` within CI jobs.

11/18/2021

This post details the technical steps and considerations for connecting a Kubernetes cluster to GitLab using the GitLab Agent for Kubernetes. It outlines the prerequisites, different connection methods (manual KUBECONTEXT, third-party tools, legacy integration, and the recommended Agent approach), and the internal workings of the Agent (`agentk` and `kas`). It provides detailed instructions for creating the agent configuration file (`config.yaml`), registering the agent via the GitLab UI or Terraform (including Terraform module usage and CI/CD integration), and installing `agentk` using `kpt` for advanced customization. The post also discusses agent deployment strategies for larger setups, recommending separate agents per environment or squad for better management and security.

11/15/2021

This post announces the deprecation of the certificate-based Kubernetes integration in favor of the GitLab Agent for Kubernetes. It explains the reasons for this shift, including security risks, privilege escalation issues, and the industry's move towards pull-based deployments. The post details the advantages of the Agent, such as configuration-as-code, improved security with RBAC, scalability, GitOps support, and enhanced integration capabilities. It also outlines the roadmap for the Agent, focusing on observability, Auto DevOps, and GitLab-Managed Clusters, and requests user feedback for prioritization.

10/21/2021

This post introduces the concept of GitOps and outlines a series of tutorials on how to use GitLab for GitOps delivery. It explains DevOps, SRE, Infrastructure as Code (IaC), and containers in the context of GitOps. The series will cover provisioning infrastructure with Terraform, connecting Kubernetes clusters using the GitLab Agent, secrets management, managing cluster connections from code, integrating clusters into GitLab for monitoring and security, and application deployment with Auto DevOps.

10/19/2021

This post introduces the pipeline editor for validating and previewing CI/CD YAML configurations, including live linting and the ability to inspect merged YAML. It also highlights the package registry for various package managers and container images, and the secret detection template for securing secrets within CI/CD pipelines. Advanced release and continuous delivery features like canary deployments and GitLab Pages are mentioned, along with examples of using CI/CD templates for Docker builds and SAST.

9/15/2021

This post details how QPage, a company providing recruitment solutions, migrated to GitLab's DevOps Platform to accelerate their deployment process. They utilize GitLab's CI/CD integrations, specifically the GitLab-Kubernetes integration for building, testing, and deploying to clusters, and Auto DevOps for automating the CI/CD process. They also leverage the Docker-GitLab integration for containerized workflows, pushing images through GitLab CI before deployment. The post highlights a significant reduction in deployment time from 6-8 hours to 15-20 minutes, and mentions integration with JIRA for notifications and ticket assignment, though some aspects of this process are still manual.

9/10/2021

This post details the technical steps and configurations required to deploy the GitLab Agent for Kubernetes (`agentk`) with limited permissions. It explains how to configure the agent to operate within specific namespaces by defining custom `Role` and `RoleBinding` resources, and how to limit its cluster-wide access using `ClusterRole` and `ClusterRoleBinding`. The post provides a comprehensive `agentk.yaml` manifest that includes the creation of namespaces, service accounts, deployments, and the necessary RBAC configurations to restrict the agent's write and read access to designated namespaces ('dude') while preventing access to others ('naww'). It also outlines the process of creating the agent record in GitLab and setting up the Kubernetes secret for the agent token.

8/26/2021

This post details a specific compatibility issue between Alpine Linux 3.14-based container images and older versions of Docker Engine (prior to 20.10.6), particularly affecting Docker-in-Docker (dind) scenarios common in GitLab CI/CD. It explains the root cause related to `musl` and `runc` updates in Alpine 3.14, the impact on CI/CD jobs, a temporary workaround using Alpine 3.13, and the definitive solution of updating both the host Docker Engine and the `docker:dind` image to at least version 20.10.6. It also notes that GitLab.com instance runners have already been upgraded.

8/24/2021

Introduced the concept of stageless pipelines in GitLab CI/CD, enabled by the `needs` keyword. This allows jobs to define direct dependencies on other jobs, bypassing the traditional stage-based execution order. This feature aims to further accelerate CI/CD pipelines by allowing jobs to run as soon as their prerequisites are met, rather than waiting for an entire stage to complete. The post clarifies that stages are not being removed but that stageless pipelines offer an alternative for greater flexibility.

8/17/2021

This post introduces the "GitLab HA Scaling Runner Vending Machine for AWS," an Infrastructure as Code (CloudFormation) solution for deploying and managing elastic GitLab Runners on AWS. It focuses on cost savings through AWS Autoscaling Groups (ASG), Spot compute instances, scheduled uptime, and ARM architecture (Graviton). The post details how to configure jobs to leverage Spot runners and includes an example of using the `retry:` keyword for resilience. It also provides a cost savings calculation demonstrating up to 97% reduction by combining scheduling, Spot, and ARM.

7/29/2021

This post introduces the GitLab pipeline editor for visual authoring and validation of CI/CD configurations, and highlights the GitLab Agent for Kubernetes for GitOps deployments. It frames these as key components of GitLab 14's strategy to improve the speed and confidence of software delivery within a modern DevOps framework.

7/29/2021

This post introduces the 'to be continuous' initiative, an open-source project providing reusable GitLab CI/CD pipeline templates. It addresses the challenges of CI/CD standardization, DevOps expertise, and DevSecOps in large companies. The initiative offers templates for various stages of the software development lifecycle, including build, test, code analysis, packaging, infrastructure, deployment, and acceptance testing. It also includes an interactive configurer and example projects to simplify adoption and promote standardization.

7/23/2021

This post details a push-based (agentless) GitOps approach using GitLab's scripting and variable capabilities. It demonstrates how to use Docker, kubectl, Helm, and Ansible within CI/CD pipelines to create, shape, and modify infrastructure components. It also shows how project/group variables can be used to modify infrastructure, such as updating the number of production pods in a Kubernetes cluster. The post emphasizes the benefits of this approach for non-Kubernetes infrastructure and for situations where agent installation is not desired.

7/19/2021

This post introduces the integration of Gitpod with GitLab, enabling cloud-based development environments. It details how Gitpod allows for rapid provisioning of pre-configured development environments, reducing onboarding time and ensuring consistency across teams. The post covers setting up a VueJS application with Gitpod, including configuring `vue.config.js` to disable host checks and installing the GitLab workflow VS Code extension. It also provides an example of using Gitpod for a Hugo Pages website with a `.gitpod.yml` configuration for live review.

7/12/2021

This post provides a historical overview of operations evolution, from System Administrators to SRE, public cloud adoption, the emergence of DevOps and containerization (Docker, Kubernetes), culminating in the concept of GitOps. It frames GitOps not as a new technology but as a summary of best practices for infrastructure as code and automation, enabled by tools like Kubernetes. It also positions GitLab's platform as supporting these practices through its CI/CD and Kubernetes management features, encouraging users to focus on building a strong DevOps culture.

6/21/2021

This post introduces strategies to enhance GitLab CI/CD pipeline productivity. It details the use of Directed Acyclic Graphs (DAG) with the `needs:` keyword to enable concurrent job execution, reducing pipeline wait times. It also explains how `parallel:` keyword increases work productivity by running multiple instances of a job simultaneously, and how `parallel: matrix:` jobs break down large pipelines into manageable parts. The post further discusses parent/child pipelines for better dependency management in monorepos and introduces merge trains for stable target branches. Finally, it highlights the ability to configure multiple caches in a single job for performance gains and explains how efficient pipelines can save money.

5/11/2021

This post details the refactoring of the GitLab pipeline graph to accurately depict job dependencies ('needs' relationships) instead of the previous 'placebo lines' that indiscriminately connected jobs between stages. It explains the technical challenge of calculating these lines due to potential performance costs (8000+ connections) and the phased rollout strategy: first shipping the refactored graph without lines, and then planning to reintroduce improved lines in a future release. It also mentions the rollout of the new Job Dependencies view.

5/5/2021

This post details the evolution and current state of GitLab's Auto DevOps feature, highlighting user feedback and future directions. Key technical points include: Auto DevOps ties together 15 stages from building to deployment, supports customization, and was released in GitLab 11.0. User feedback indicates issues with speed (especially Auto Testing), troubleshootability, scalability (leading to forked versions), and limited deployment targets (primarily Kubernetes, with recent additions of AWS EC2/ECS). The post outlines two target user personas: larger companies with platform teams requiring standardization and smaller companies without dedicated teams needing convention-over-configuration solutions. A design sprint is planned to reimagine Auto DevOps, focusing on addressing these feedback points and expanding deployment support.

4/27/2021

This post details three methods for employing GitOps principles using GitLab: push using manually configured CI/CD release targets (for Kubernetes and non-Kubernetes environments), push using Terraform (for Kubernetes and non-Kubernetes environments supported by Terraform), and pull using a Kubernetes agent (for Kubernetes environments only). It also outlines an upcoming 'push using a Kubernetes agent' approach for Kubernetes environments.

4/6/2021

This post details the integration of GitLab CI/CD with Rasa X for automating the build and deployment of custom action Docker containers to a Kubernetes cluster. It outlines the use of .gitlab-ci.yml to define variables for Docker image naming and Kubernetes secrets, and stages for building the Docker image (including login to GitLab registry, building and pushing the image) and deploying to Kubernetes (including GCP authentication, namespace creation, secret creation, Helm chart addition, and Helm upgrade with custom image tag and pull secrets).

2/22/2021

This post details research into customer adoption hurdles for GitLab's Verify functionality, specifically focusing on Continuous Integration. Key learnings include that while developers love GitLab, enterprises have high expectations for polished features and low tolerance for experimentation. A significant challenge identified is the lack of visibility into job performance at scale, making it difficult to diagnose problems. The post outlines the path to 'Lovable' maturity for CI, focusing on improving Artifacts and Variables performance, and future plans to address visibility challenges in job and pipeline activities.

2/22/2021

Introduced the Pipeline Editor, a dedicated UI for authoring `.gitlab-ci.yml` files. This editor provides continuous validation of pipeline configurations, a visualizer to preview pipeline structure before execution, an expanded view that merges `include` and `extends` directives for better readability, and an integrated CI linter for detailed job information. The editor aims to simplify CI/CD configuration for both new and experienced users.

1/22/2021

This post details GitLab's Auto DevOps feature, which provides pre-configured CI/CD templates that automatically detect, build, test, deploy, and monitor applications. It outlines the various stages and jobs within the Auto DevOps pipeline, including build, test (static analysis, security, dependency, license, secrets exposure, unit tests), review (DAST), staging deployment, incremental production deployment, performance testing, and cleanup. It also explains Auto Review Apps for ephemeral environments and methods for customizing Auto DevOps via environment variables, pipeline editing, or reusing specific templates.

1/20/2021

This post introduces the use of the `parallel` keyword in GitLab CI/CD to split a single job (`frontend-fixtures`) into multiple parallel instances. It details the modification of the `.gitlab-ci.yml` file to include `parallel: 2` and explains how this resulted in two jobs (`rspec-ee frontend_fixture 1/2` and `rspec-ee frontend_fixture 2/2`) that executed concurrently. The post also mentions further optimization by splitting the longest-running fixture generator file into smaller batches, shaving off additional time. It provides tips for identifying bottlenecks and leveraging the `parallel` keyword for productivity gains.

12/15/2020

This post introduces the "5 minute production app" initiative, demonstrating a streamlined workflow from code to production deployment using GitLab UI, AWS, Terraform, and Auto DevOps. It highlights the challenges of adopting microservices and Kubernetes, and presents a solution that automates provisioning, database setup (AWS Aurora RDS), container image building and deployment, and application monitoring, aiming to reduce the time to production to 5 minutes. It also discusses the decision to use container images and the GitLab Container Registry for packaging and distribution.

12/10/2020

This post introduces and explains the use of `stages` for sequential job execution, `needs` for defining job dependencies and enabling Directed Acyclic Graphs (DAGs) for more flexible pipeline execution, and the `image` keyword to specify custom Docker images (like `alpine`) for CI jobs to reduce build times. It also covers artifact management with `paths` and `expire_in`, and the use of `before_script` for setup tasks within specific jobs.

12/8/2020

This post introduces the Jenkins Importer category direction to streamline Jenkins to GitLab CI/CD migrations. It details the development of a wrapper around Jenkinsfile Runner to allow running Jenkins stacks within GitLab during migration, and proposes tools for converting declarative, imperative, and scripted Jenkins configurations to `.gitlab-ci.yml`.

12/1/2020

Introduces CML (Continuous Machine Learning) to adapt CI systems for ML use cases, enabling automatic model training, testing, and rich reporting within merge requests. Details how to integrate CML with GitLab CI for basic reporting of model metrics and confusion matrices, and further integrates with DVC for data version control, allowing for the visualization of metric differences and loss function plots.

11/13/2020

The post details the author's experience setting up GitLab CI for a .NET project, including the challenges faced with Windows runners and the eventual adoption of Docker images for build and test stages. It provides a sample `.gitlab-ci.yml` for .NET builds and tests, including configurations for OpenCover, NUnit, and Chrome headless for UI tests. The author also mentions contributing to the GitLab Triage project to automate workflows.

11/9/2020

This post details how GitLab Auto DevOps and Managed Apps were adapted to the deprecation and removal of the Helm Stable repository. The mitigation involved switching to a GitLab-maintained Helm Stable Archive repository. Specific version upgrades for `auto-deploy-image` and `cluster-applications` are provided as solutions for users experiencing pipeline failures.

10/30/2020

This post introduces and details the implementation of a Docker Hub registry mirror to address Docker's new pull rate limits. It provides instructions for self-hosted GitLab Runners on how to set up and configure a Docker registry mirror, including Docker commands and `daemon.json` configuration. It also mentions the use of Google's Docker Hub images mirror for GitLab.com Shared Runners and briefly touches upon alternatives like authentication.

10/1/2020

This post provides three tips for writing better YAML configurations for CI pipelines: 1. Utilize formatting tools and linters (like the GitLab CI lint) to ensure correct syntax and indentation. 2. Keep YAML configurations simple by including only necessary data and avoiding gratuitous indentation. 3. Reuse configuration where possible using the `include` keyword, `extends`, and anchors to maintain consistency and reduce duplication. It also highlights the availability of CI/CD pipeline templates.

9/22/2020

Introduced the capability to manage Composer packages within GitLab instances. This includes automated package creation via CI/CD templates triggered by Git tags or branch pushes, and manual creation using the GitLab API. The post also highlights areas for future improvement, such as enhancing the GUI with package size and publication details, and improving semantic versioning support.

9/17/2020

This post details the integration of GitLab CI/CD with Linux on IBM Z and Red Hat OpenShift, enabling the execution of GitLab Runners on these resilient systems. This includes support for SSH executors on Mainframes and the GitLab Runner Operator for Red Hat OpenShift, allowing cloud-native pipelines to run on these platforms.

9/8/2020

This post details GNOME's extensive adoption and utilization of GitLab CI/CD following their migration. Key technical contributions include the use of CI/CD for building testing images, which was a new capability enabled by GitLab. The post also highlights the increased awareness and usage of CI/CD across the GNOME project, leading to shorter feedback loops for development and testing, and efforts to optimize CI/CD workflows for efficiency.

7/31/2020

This post introduces a method to build container images using GitLab Runner on AWS Fargate when Docker-in-Docker (DinD) is not supported due to Fargate's lack of privileged mode. It details the architecture overview, prerequisites, and a six-step process involving creating an S3 bucket, an AWS CodeBuild project, building a custom CI container image with AWS CLI and zip, adding a buildspec.yml to the repository, setting up a GitLab CI job to orchestrate the process (zipping build files, uploading to S3, triggering CodeBuild via AWS CLI, and fetching logs), and configuring AWS credentials. The core technical contribution is the orchestration script and CI job configuration that bridges GitLab CI with AWS CodeBuild for container image building.

7/29/2020

This post provides practical tips for optimizing CI/CD pipelines, focusing on speed, resource efficiency, security, and integration. It details how to achieve faster builds using autoscaling runners (GKE, AWS Fargate), leverage Auto DevOps, create build images, implement cross-project pipelines, and integrate with external services like Firebase for continuous deployment. Security aspects covered include understanding the threat landscape and integrating with Vault. It also mentions specific integrations for AWS SAM deployments and Android projects.

7/16/2020

This post details how CI/CD automation has reduced manual tasks in software development, leading to a shift in Dev and Ops roles. Developers are spending less time on manual testing and deployments, and more time on code quality, testing, and infrastructure definition. Operations teams are focusing more on managing cloud services and infrastructure. The post uses survey data and anecdotal evidence to illustrate these changes.

7/9/2020

This post details how to integrate Azure DevOps repositories with GitLab CI/CD. It explains two primary methods: 'CI/CD for external repositories' and 'Remote repository mirroring'. The post provides step-by-step instructions for setting up the integration, including creating a new project in GitLab, selecting the 'CI/CD for external repo' option, cloning the Azure DevOps repository URL, and configuring credentials for private repositories. It also outlines how to trigger CI/CD pipelines in GitLab by either enabling Auto DevOps or by adding a `.gitlab-ci.yml` file to the Azure DevOps repository. A suggested development workflow is presented, illustrating how commits to Azure DevOps trigger builds, tests, and deployments in GitLab, and how pull requests can be managed in Azure DevOps while leveraging GitLab for CI/CD.

6/24/2020

This post details the evolution of GitLab's Sidekiq architecture to scale asynchronous workload processing. It describes the shift from a many-to-many relationship between Sidekiq jobs and Sidekiq roles to a one-to-one relationship, where each job executes on exactly one Sidekiq role. It also introduces the concept of queue selectors based on workload classification (urgency, external dependencies, CPU/memory bound) to ensure predictable job execution and meet SLAs. The post highlights performance improvements achieved by optimizing Redis BRPOP commands and reducing the Sidekiq fleet size.

6/18/2020

This post details changes to GitLab.com's CI/CD job artifact and metadata expiration policies. Effective June 22, 2020, new job artifacts will default to a 30-day expiration. Existing artifacts created between October 22, 2019, and June 22, 2020, will have their expiration set to 1 year from creation. Artifacts created before October 22, 2019, will expire on April 22, 2021. Jobs older than 12 months will be archived starting June 22, 2020, with this threshold gradually reducing to 3 months by September 22, 2020. New build data and job metadata will be archived 3 months after creation. Users can override artifact expiration using the 'expire_in' keyword. The benefits include improved performance, reliability, and reduced operational costs.

6/1/2020

This post details updates to the Pajamas Design System (semantic releases, conventional commits, component status table), usage guidelines (Progress Bars, File Uploaders, button positioning, banner dismissal, data visualization color palette), GitLab UI (UX Reviewers, foundation for using GitLab UI in Docs, markdown typescale, removal of documentation link from scoped labels, standardized alert styling, filters, dropdown styles, loading button, filter/sorting component guidance), Figma migration (new components, deprecation of Sketch UI Kit, Project/Team library structure, collaboration guidance), icon updates (issue templates moved to GitLab SVGs, new icons for Project/group/subgroup, Expire, Container image), and GDK improvements (GDK doctor checks for Ruby gems, 'quiet' mode for bundle installation, restructured documentation, YARD documentation generation, Webpack modes, Grafana configuration doc). It also covers CI enhancements (shell script checking, Vale linting, RuboCop integration, CI config templating, interruptible CI jobs by default) and miscellaneous updates (Sidekiq logging to JSON by default).

5/28/2020

This post introduces and demonstrates the integration of the GitLab Web IDE with GitLab CI/CD pipelines and Auto DevOps. It details how users can make code changes, commit them, trigger automated pipelines for testing and security scanning, and deploy applications, all within the GitLab interface. It highlights the ease of use for non-developers and the end-to-end workflow from code change to deployment, including the use of Review Apps and the handling of security vulnerabilities found during scans.

5/27/2020

This post details F5 Networks' experience managing GitLab CI jobs on Kubernetes runners. It highlights a critical incident where a bug in CI job scheduling led to exponential job creation, threatening to overload the system. The post outlines the fix for this incident (disabling CI on the rogue project and canceling pending jobs) and the subsequent implementation of monitoring and alerting to prevent recurrence. Furthermore, it provides specific configurations for setting CPU and memory limits on Kubernetes runners to prevent resource exhaustion and discusses the importance of using labels for debugging and data analysis in Kubernetes environments.

5/15/2020

This post announces the delivery of official support for 32-bit and 64-bit Arm-based GitLab runners in binary, rpm/deb packaging, and Docker image format. This includes making Arm Runner binaries available in the 12.6 release, RPM/DEB packages in the 12.9 release, and native Arm Docker images in the 13.0 release. GitLab has also released a demo showing deployment on AWS Graviton2 M6g Instances, joined the Arm Neoverse developer program, and is adding support for Arm architectures for Auto DevOps and Omnibus.

5/12/2020

Introduced the Directed Acyclic Graph (DAG) feature for GitLab CI/CD pipelines, enabling jobs to run out of order based on direct dependencies rather than strict stage sequencing. This is achieved through the new `needs` keyword in `.gitlab-ci.yml`, which allows jobs to start immediately after their specified dependent jobs complete, irrespective of their stage. This significantly reduces pipeline execution time, particularly for monorepos with independent build/test/deploy workflows.

5/12/2020

This post explains how GitLab CI/CD addresses common DevSecOps challenges by providing a unified platform that eliminates toolchain complexity, silos between development, security, and operations teams, and improves visibility across the SDLC. It emphasizes the benefits of a single application for CI/CD, including increased efficiency and industry-leading capabilities, contrasting it with fragmented toolchains.

5/11/2020

Introduced a custom executor driver for GitLab Runner to enable autoscaling of CI jobs on AWS Fargate. This driver utilizes the AWS Fargate `run-task` action to schedule new tasks, where each task runs a container built from a specific image containing necessary build tools. The driver divides the CI job into Config, Prepare, Run, and Cleanup stages and includes capabilities for SSH connectivity between the driver and the build container. A limitation noted is the inability to run containers in privileged mode, preventing Docker-in-Docker on Fargate.

5/6/2020

This post details breaking changes and updates for GitLab 13.0, specifically impacting Auto DevOps configurations, CI/CD templates, and GitLab Runner. It highlights the transition of Auto DevOps and Secure configuration templates from `only/except` to `rules` for improved job execution logic. It also announces the default PostgreSQL chart version change to 8.2.1 for Auto DevOps and the `deploymentApiVersion` change to `apps/v1` to support Kubernetes 1.16. Furthermore, it outlines several breaking changes in GitLab Runner 13.0, including the deprecation of Windows Batch for the shell executor, changes to API endpoints, removal of the `--docker-services` flag, removal of a legacy caching feature flag, and end-of-life support for specific OS versions. Finally, it mandates the use of the new `License-Scanning.gitlab-ci.yml` template for License Compliance.

5/6/2020

This post introduces the integration of review apps for Android within GitLab CI/CD pipelines. It details how to leverage `fastlane` with Appetize.io to deploy Android APKs as review apps. Key technical contributions include: defining a new `review` lane in `fastlane` to push apps to Appetize.io, configuring `.gitlab-ci.yml` to trigger this lane for non-master branches, implementing dynamic environment URLs by capturing the Appetize.io public key and using a `dotenv` artifact, and optimizing updates by fetching the previous build's public key to update existing apps instead of creating new ones. It also includes a `stopReview` job to clean up Appetize.io apps when a branch is deleted.

4/30/2020

This post details upcoming improvements to Auto DevOps, including support for Cloud Native Buildpacks, air-gapped networks, Helm 3, NGINX alerts to auto-monitoring, and Merge Train support. It also mentions a future direction towards a DAG approach for Auto DevOps pipelines.

4/29/2020

This post details how GitLab CI/CD can be used with AWS Serverless Application Model (SAM) to build, test, and deploy AWS Lambda applications. It covers using and installing the AWS SAM CLI, creating a SAM application with a Lambda function and API, and automating the build, test, and deployment process using GitLab CI/CD. It also explains the benefits of SAM for enterprise teams and the advantages of serverless computing.

3/27/2020

This post details the integration of GitLab CI/CD with Google Kubernetes Engine (GKE). It outlines the prerequisites for this integration, including a configured GitLab instance with Google OAuth2 OmniAuth Provider and a Google Cloud project with necessary APIs enabled. The post provides a step-by-step guide for administrators to add a Kubernetes cluster on GKE, install Helm Tiller, and then install the GitLab Runner application on the cluster. This enables shared runners for CI pipelines directly on GKE, with guidance on configuring the number of nodes for simultaneous job execution.

3/16/2020

This post details the integration of GitLab CI/CD with Google Firebase for automating application deployments. It covers acquiring a Firebase API key, configuring the `.gitlab-ci.yml` file to install the Firebase CLI, and setting up deployment jobs for Firestore, Firebase Functions, and Firebase Hosting. The post demonstrates how to use the `only` and `changes` keywords in `.gitlab-ci.yml` to trigger deployments for specific infrastructure components based on changes in the repository, and how to secure the Firebase token as a protected and masked CI/CD variable.

2/20/2020

Introduced the use of manual jobs in GitLab CI/CD pipelines, specifically detailing how to leverage protected environments to limit access to deployments and how to configure manual jobs with `allow_failure: false` to act as approval steps before subsequent stages. This enhances control over production deployments and aids in meeting compliance requirements.

1/30/2020

This post introduces and details the 'merge trains' feature for GitLab CI/CD. It explains the problem of maintaining a green master branch with high merge volumes and how merge trains solve this by sequencing merge requests and running pipelines immediately. It also covers the evolution of the feature, including tuning concurrency, adding warnings for immediate merges, and supporting squash & merge. Future plans for fast-forward merge support and API support are also mentioned.

1/27/2020

This post details the integration of Pulumi and ephemeral environments into the GitLab CI/CD pipeline for acceptance testing. It explains how to set up ephemeral environments that mimic production but are scoped to first-level dependencies, using Pulumi to define and provision infrastructure (GCP resources like Pub/Sub topics and storage buckets) and Kubernetes deployments. The acceptance tests are run as Kubernetes jobs within these ephemeral environments, providing a quality gate before production. The pipeline includes stages for testing, building Docker images with Kaniko, spinning up ephemeral environments with Pulumi, running acceptance tests, and cleaning up resources.

1/24/2020

This post details how GitLab CI was leveraged to facilitate the upgrade of bootstrap-vue in gitlab-ui. It explains the use of `yarn pack` to create a tarball of an NPM package from a CI job, which is then published as an artifact. This artifact serves as a private registry for development branches, allowing other projects (like GitLab itself) to install and test unreleased versions of the package using `yarn add @gitlab/ui@$DEPENDENCY_URL`. This enabled iterative fixing of breaking changes and collaborative migration. The post also details specific breaking changes in bootstrap-vue 2.0, including import syntax, slot syntax for `BTable` and `BTab`, and refactoring of tooltip/popover components, along with strategies for migrating failing Karma tests to Jest and using `attachToDocument`.

1/21/2020

Introduced the `resource_group` attribute to `.gitlab-ci.yml` to limit concurrent job execution to a single job per defined resource group. This addresses issues where concurrent deployments to shared physical resources caused errors and unintended consequences. Jobs assigned to the same resource group will now queue if another job is already utilizing it.

1/21/2020

Introduced Windows Shared Runners beta on GitLab.com, offering a fully-managed, auto-scaling, and secure environment for Windows CI/CD jobs. These runners are pre-configured with common software packages and utilize the custom executor, with each job running in an isolated VM instance that is deleted after completion. Pricing is initially aligned with Linux Runners, deducted from the Runner minute pool. Notable limitations include longer provisioning times (average 5 minutes) and longer pending queue times compared to Linux Shared Runners. The Windows Shared Runners do not use the Docker executor, meaning 'image' and 'services' cannot be specified in pipeline configurations. Users needing additional software not pre-installed must add installation commands to their scripts, which will be repeated for each job due to the ephemeral nature of the VMs.

1/14/2020

This post introduces a new project template for serverless JavaScript projects within GitLab. It details the steps to create a project using this template, configure AWS credentials (access key ID and secret access key) in GitLab CI/CD variables, and deploy an AWS Lambda function. The deployment process leverages GitLab CI/CD to run tests and then deploy to AWS Lambda, with the resulting application accessible via GitLab Pages. It also provides an example of modifying the function to create a simple calculator.

12/17/2019

Athlinks migrated from Jenkins to GitLab CI, reducing their job count from approximately 300 to less than 40. They are using GitLab CI for a diverse technology stack including multiple operating systems, Android, and iOS. This migration resulted in an estimated 50% savings in code and time spent running jobs. The post highlights the benefit of having issues, code, and CI pipelines within a single view in GitLab, improving collaboration and communication across marketing, DevOps, and engineering teams.

11/27/2019

This post presents the results of a survey on AWS Lambda usage habits, focusing on frameworks, testing, CI/CD tools, and monitoring. It highlights the popularity of the Serverless Framework, a general lack of robust testing in serverless projects, the prevalence of GitLab for CI/CD, and the widespread use of AWS CloudWatch for monitoring. It also introduces a GitLab project template for serverless applications using GitLab Pages and AWS Lambda.

11/26/2019

This post details the migration of teams from Jenkins to GitLab CI/CD. It highlights the use of Docker to run Jenkinsfiles as a transitional step and the benefits of Auto DevOps for simplifying pipeline conversion and providing built-in security and quality testing. It also offers best practices for migration, emphasizing starting small, utilizing tools effectively, and clear communication.

11/19/2019

This post introduces the concept of securing the CI/CD pipeline as a critical aspect of DevSecOps. It outlines four key areas for defending against CI/CD pipeline risks: automation (integrating security testing at scale), access management (managing human-to-tool and tool-to-tool interactions, and securing secrets), user experience (seamless integration and immediate feedback to reduce workarounds), and transparency (logging changes, origins, and enabling sign-offs). It argues that a single CI/CD tool, like GitLab, can inherently improve security by embedding checks within the development workflow.

11/15/2019

This post details the integration of Python and Rust within a GitLab CI pipeline for building and deploying an application. It covers configuring the development environment with Rustup, Pipenv, and CPython/Py03 bindings. It also describes the process of structuring the project, writing Rust and Python code, and troubleshooting the interaction between the two languages. Finally, it explains how to Dockerize the application and set up a CI/CD pipeline for deployment.

11/15/2019

This post details an investigation into silent test failures in GitLab CI jobs, which uncovered a bug in the Docker client library code used by GitLab Runner and an unexpected change in Go TCP keepalive defaults. The investigation involved debugging CI job log handling, reproducing the bug by simplifying `.gitlab-ci.yml`, differentiating between Docker Machine and Docker executors, and analyzing network traffic to understand timeouts related to Google Cloud Platform. The issue was ultimately worked around by upgrading the Go compiler.

11/6/2019

This post introduces GitLab CI/CD as a cloud-agnostic solution that supports multi-cloud strategies. It contrasts GitLab CI/CD with cloud-provider-specific tools like GitHub Actions, emphasizing GitLab's ability to provide a consistent DevOps platform across any cloud, enabling workflow portability and flexibility. The post highlights the benefits of multi-cloud for organizations, including greater flexibility, better acquisitions, increased resilience, improved cloud negotiations, and fewer conflicts of interest. It also discusses the challenges of cloud providers truly supporting multi-cloud due to their inherent interest in vendor lock-in.

11/5/2019

This post details adSoul's migration from Jenkins to GitLab CI. The migration was executed in three phases: repository migration (using GitHub Import and a custom issue migrator), CI/CD pipeline migration (involving a 'lift and shift' of processes and a pro-tip to increase log limits for debugging), and CI/CD pipeline improvement (splitting projects into single-purpose jobs, moving to Gradle for build time improvement, implementing parallel job processing, and using standard Docker images). Key takeaways emphasize planning, a step-by-step approach, rethinking DevOps strategy, and starting with small projects. The benefits of GitLab CI for small teams, such as low maintenance, customization, and branch independence, are also highlighted.

10/18/2019

This post contrasts the complexity and silo-inducing nature of Jenkins' plugin-based architecture with GitLab CI/CD's single-application approach. It details Jenkins' challenges: maintaining build environments, risky upgrades, difficult Groovy maintenance, and lack of clustering. It argues that this complexity leads to knowledge gaps and a 'throw it over the wall' dynamic. The post then positions GitLab CI/CD as a solution that integrates SCM, issue tracking, security testing, and monitoring within a single interface, thereby improving visibility and fostering better DevOps practices.

10/8/2019

This post details the use of GitLab Runners on Arm instances for multi-architecture builds, specifically for edge base research projects. It highlights the collaboration between GitLab and Arm in enabling cross-architecture CI/CD, including running GitLab's 64-bit Runner on Arm instances on public cloud providers like Packet Cloud and AWS. It also mentions the use of Fluent Bit for stream processing on the edge and the CNCF CI Working Group's efforts in building and testing projects on both x86 and Arm architectures within a Kubernetes test environment.

10/7/2019

This post introduces and explains GitLab's Auto DevOps feature, which provides a pre-configured CI/CD pipeline with automated best practices for code quality, security scanning (dependency, license, container), DAST, and deployment. It highlights the 'shift left' movement by integrating security checks early in the pipeline. The post also mentions the composable Auto DevOps option for customization and the automatic browser performance testing and auto monitoring for applications in production.

10/3/2019

This post details GitLab's unconventional journey from feature freezes to continuous delivery (CD) and the subsequent migration to Kubernetes. It highlights the inefficiencies of the previous release process, including feature freeze periods and manual release tasks, and quantifies the time spent by the Delivery team on these activities. The post explains GitLab's strategy of first building a CD system using existing tools and reorganizing infrastructure to 'stress test' the current system before migrating to Kubernetes. This approach aimed to expose and stabilize application weaknesses, strengthen the application, and foster a cultural shift towards a CD mindset among engineers. The new CD process automates 90% of the release process, with a focus on automated QA, progressive rollouts, and on-call rotations for developers. Key technical challenges identified include ensuring sufficient QA coverage and communicating process changes across engineering teams.

10/1/2019

This post details Redbox's adoption of GitLab CI with Fastlane for modernizing their software development processes, their use of GitLab CI with Spinnaker for speeding up cloud delivery, and how GitLab Enterprise empowered their developers to own their applications. It also highlights their migration to GitLab from multiple disparate source control systems, emphasizing its on-prem and cloud support, and its ability to allow developers to control their namespaces. The post also mentions the flexibility of GitLab to integrate with other tools like Jenkins, Jira, JFrog Artifactory, and Spinnaker.

9/27/2019

This post highlights the inherent risks and maintenance burdens associated with plugin-based extensibility in CI/CD systems, using Jenkins as a primary example. It details security vulnerabilities stemming from third-party plugins, the fragility of pipelines due to complex dependency chains, and the significant administrative overhead required for plugin maintenance and upgrades. The post contrasts this plugin-centric approach with an all-in-one solution, suggesting that while plugins offer customization, they introduce significant technical debt and security concerns. It briefly mentions GitLab's use of plugins but implies a preference for integrated solutions for core functionalities.

9/26/2019

This post details the integration of GitLab CI/CD with Kubernetes, specifically highlighting the Auto DevOps functionality. It explains how to spin up a Kubernetes cluster (using Digital Ocean as an example), integrate it with a GitLab project using a kubectl plugin, install GitLab-managed applications (Helm, Ingress, Prometheus, Cert-Manager, GitLab Runner), and launch Auto DevOps with a single click. It also explains how to leverage the open-source Auto DevOps YAML file to customize individual pipeline stages like build and deploy, including the use of Docker for containerization and Helm for deployment.

9/20/2019

This post analyzes the competitive landscape of CI/CD tools, specifically comparing GitLab CI with Jenkins and its ecosystem. It highlights Jenkins' reliance on acquisitions (Electric Cloud, Codeship) and plugins for CI/CD capabilities, and contrasts it with GitLab's integrated approach. It also mentions Jenkins X as a cloud-native CI/CD solution for Kubernetes and the CloudBees SDM Platform as an end-to-end solution. The post concludes by reiterating GitLab's value proposition as an all-in-one platform.

9/11/2019

Introduced and explained 'Pipelines for Merged Results' which runs CI pipelines on merge commits generated from the latest target and source branches before merging, providing an 'untrusted' pipeline result. Also introduced 'Merge Trains' as a queueing system to avoid race conditions between concurrent merges by creating sequential merge commits and running pipelines on them, dropping problematic MRs from the train.

8/28/2019

This post introduces the concept and implementation of building custom Docker 'build images' as a meta-step within GitLab CI/CD pipelines. It details how to use the `docker:stable` image with `docker:dind` service to build a Docker image containing specific dependencies (e.g., `firebase-tools`) and push it to the GitLab Container Registry. The post demonstrates how subsequent jobs can then use this custom image as their base, reducing pipeline execution time and dependency on external Docker Hub images. It also highlights the use of built-in CI/CD variables for registry authentication and the `only: changes` keyword for conditional image rebuilding.

8/26/2019

This post introduces the capability to integrate budget and resource checking into CI/CD pipelines. It outlines the importance of these checks to avoid rollbacks, redeployments, and long analysis for budget overruns. It suggests using tools like CloudHealth by VMware and GitLab scripts to implement these checks, focusing on project-specific budgets and resource limits. The post also recommends adding a budgetary efficiency metric for DevOps admins.

8/21/2019

Introduced autoscaling for GitLab Runners, enabling on-demand machine creation and automatic removal after job completion. This addresses the challenge of balancing runner capacity with fluctuating job loads and aims to reduce infrastructure costs by ensuring only necessary capacity is provisioned.

8/7/2019

This post details upcoming CI/CD features in the 12.x release cycle. Key additions include hybrid Directed Acyclic Graphs (DAG) for out-of-order job execution, improved pipeline rules for better clarity, and feature flag controls for progressive rollouts. It also outlines plans for associating milestones with releases, simplifying Kubernetes runner setup, enhancing GitLab Pages availability, integrating with HashiCorp Vault, extending merge request pipelines to forks, automating release evidence collection, supporting Helm v3 charts, refining workspace definitions, improving parallelization tuning, and introducing child/parent pipelines for complex orchestration. The post also mentions improvements to pipeline duration and test run trend monitoring.

7/31/2019

This post addresses a breaking change in the `docker:dind` image starting from version 19.03, where TLS certificates are automatically generated and required for communication. It provides two solutions for GitLab CI/CD users: configuring GitLab Runner to use TLS with updated volume mounts and `.gitlab-ci.yml` settings, or explicitly disabling TLS by setting `DOCKER_TLS_CERTDIR` to an empty value. It also advises specifying exact Docker image versions (e.g., `docker:19.03.0-dind`) to prevent random job failures due to new updates.

7/24/2019

Introduced the `trigger` keyword in `.gitlab-ci.yml` to enable bridge jobs that initiate downstream pipelines in other projects. This allows for cross-project pipeline execution, passing variables to downstream jobs, and specifying target branches for downstream pipelines. Enhanced pipeline graphs to visualize upstream and downstream pipeline relationships.

7/23/2019

This post details three customer migrations from Jenkins to GitLab, highlighting the benefits of GitLab's integrated CI/CD capabilities. Alteryx reduced build times from 3 hours to 30 minutes by consolidating source code management, CI/CD, code reviews, and security scanning. ANWB increased deployments and supported team autonomy by moving from Jenkins v1 to GitLab. EAB consolidated tools for faster builds and less maintenance, achieving workflow increases and planning to roll out a 'quality first' culture.

7/3/2019

This post details the technical implementation of an automated podcast generation workflow using GitLab CI/CD. It describes the steps involved: downloading group conversation videos, converting them to audio files using a daily CI job, generating an RSS feed, uploading audio files to object storage, and hosting a static site with GitLab Pages. The automation is achieved through pipeline schedules that run hourly.

6/27/2019

This post outlines four key benefits of a robust CI/CD strategy: increased speed of innovation, faster time-to-market for revenue-generating code, improved talent attraction and retention, and higher quality code/operations through specialization. It also identifies required capabilities such as robust CI/CD, containers and Kubernetes, and end-to-end DevOps lifecycle functionality, along with metrics for measuring success: cycle time, time to value, uptime, error rate, infrastructure costs, and team retention rate.

6/21/2019

This post discusses the business impact of CI/CD, highlighting how effective implementation leads to faster innovation, reduced IT budget spent on undifferentiated engineering, delayed or unrealized revenue, and improved developer productivity and happiness. It emphasizes that modernizing architecture and embracing CI/CD best practices directly contributes to these positive business outcomes.

6/19/2019

This post details the highlights of GitLab CI/CD releases 11.0 through 11.4. Key contributions include the general availability of Auto DevOps, integration of job logs into the Web IDE, security reports in the pipeline view (Container Scanning and DAST), custom instance-level templates for CI/CD, support for Kaniko for secure Docker builds, JUnit test results in merge requests, built-in Maven package repositories, interactive web terminals for CI/CD jobs, the `extends` keyword for YAML CI/CD code reuse, the introduction of Feature Flags, `only/except` rules for jobs based on file changes, and timed incremental rollouts for Auto DevOps.

6/5/2019

This post identifies three key challenges in CI/CD implementation: high maintenance and integration costs (predominantly human resources), development being slowed or blocked by operations teams due to conflicting incentives, and developers being forced to handle operational tasks. It elaborates on these challenges by describing how siloed teams and tools lead to integration issues, how delays in code reaching production and context switching demotivate developers, and how environment dependencies distract developers from business logic. The post suggests modernizing CI/CD as a solution and promotes GitLab CI/CD as a superior alternative.

5/29/2019

This post introduces the integration of GitLab CI/CD with Salesforce DX, enabling templatized pipelines that leverage Scratch Orgs and packaging for a structured and frictionless development experience. Developers can use a Git-based workflow with issue tracking and merge requests, with automated testing and deployment into Scratch Orgs upon approval, followed by packaging and deployment into Sandbox and production environments.

5/21/2019

Monkton Incorporated migrated from a 'hodge podge' of tools to GitLab, consolidating their development lifecycle. They automated manual processes such as uploading code scans to Fortify and are working on automating the publishing of mobile applications to MDM. The company's vision is to automate the entire testing, deployment, and security vulnerability scanning lifecycle from code check-in to production, reducing human error and enabling repeatable, consistent outcomes.

5/21/2019

This post highlights GitLab CI/CD's collaboration with the Fluentd project, showcasing how GitLab supported Fluentd's CI needs and provided guidance on converting their pipelines. It emphasizes GitLab CI/CD's capability to support influential open-source projects.

5/1/2019

This post discusses the trend of concurrent DevOps and how autoscaling runners can be used to improve CI testing pipelines. It mentions GitLab's capabilities in this area and links to a Medium article about building a CI testing pipeline with GitLab CI. This contributes to the existing feature thread by providing an external perspective on how GitLab's CI/CD features enable concurrent DevOps practices.

4/25/2019

This post showcases five customer success stories of teams migrating from legacy CI/CD tools (Jenkins, Travis) to GitLab CI/CD. It details the specific benefits achieved by each team, including reduced deployment times (e.g., Verizon Connect from 30 days to under 8 hours, Ticketmaster's pipeline from 2 hours to 8 minutes), cost reductions (HumanGeo by 33%), improved efficiency, and simplified development processes. The post also mentions a webcast on mastering continuous software development with GitLab CI/CD.

4/16/2019

Introduced an improvement to MR Pipelines in the 11.10 release that builds the combined ref (source + target branch) as part of the merge request pipeline. This requires users of private GitLab Runners on versions 11.8 or older to upgrade to 11.9 or newer to avoid an 'Your runner is outdated' error. Shared Runner fleet users are not impacted.

4/2/2019

This post introduces the core value proposition of GitLab CI/CD, highlighting its integrated nature as a solution to common DevOps challenges such as complex toolchain integrations, brittle tools, and slow modernization. It emphasizes ease of use through YAML configuration, cloud-native compatibility with built-in container registry and Kubernetes integration, a simple architecture, and efficient autoscaling runners. It positions GitLab CI/CD as a comprehensive solution for the entire DevOps lifecycle, contrasting it with fragmented toolchains.

4/1/2019

This post introduces the integration of ZEIT Now with GitLab, enabling automated builds and deployments for every commit pushed to GitLab projects. It details how this integration enhances the developer workflow by providing unique URLs for each deployment, listing deployments chronologically on merge request pages, and automatically aliasing merged MRs to production domains. The post also outlines the setup process, including connecting GitLab accounts and preparing projects with a `now.json` configuration file, and highlights the benefits of custom domain names and instant rollbacks.

3/26/2019

This post details the technical steps and configuration required to integrate GitLab CI/CD with Pantheon for automated deployments. It covers setting up SSH keys for secure access between GitLab and Pantheon, configuring GitLab CI/CD variables for Pantheon site name and Git URL, and defining a `deploy:dev` job in `.gitlab-ci.yml` to push code from the GitLab `master` branch to the Pantheon development environment. It also outlines the process for setting up Pantheon Multidev environments for merge requests, enabling on-demand deployments for independent work and QA.

3/25/2019

This post details a security vulnerability in quick actions for issues that could expose project runner registration tokens to unauthorized users. It describes the response and mitigation, including applying a patch on GitLab.com and expediting a critical security fix for self-managed customers. It also outlines the action required for GitLab.com users with automation relying on runner registration tokens (resetting tokens) and reports the results of the investigation, stating no evidence of security compromise but a commitment to further investigation and security posture improvement.

3/21/2019

This post announces an extension of the free trial period for CI/CD for external repositories (including GitHub) on GitLab.com until September 22, 2019. It reiterates the value proposition of using GitLab CI/CD with code hosted on other platforms and highlights the commitment to open source by offering all features of Gold for free to public projects. The reasons for the extension include the need for better instrumentation for user notification, the evolving CI/CD market landscape, and the desire to gather more user feedback.

3/6/2019

This post details the integration of GitLab CI with fastlane for automated iOS app building and publishing to TestFlight. It covers the setup of CI/CD runners on macOS, the initialization of fastlane with `Appfile`, `Fastfile`, and `Gymfile` configurations, and the `.gitlab-ci.yml` file to orchestrate the build, signing, and deployment process. It also highlights the necessary environment variables for authentication with Apple's services.

1/21/2019

This post details several key enhancements to GitLab CI/CD in 2018. It highlights the introduction of access control for GitLab Pages (community contribution), the capability to create and manage feature flags, and the `only/except: merge_requests` keyword for merge request pipelines. Usability improvements for the merge request widget include JUnit XML Test Summary, enhanced information on running deploys, and direct links to changed pages in Review Apps. The post also notes the consistent naming of status checks to support GitHub-integrated CI workflows and the move of the `include:` keyword from paid to free tiers. Honorable mentions cover manual environment stopping, improved `include` handling, path-based job execution, interactive web terminal for Docker executor, timed deployments in AutoDevOps, the `parallel` job keyword, and pipeline deletion by project owners.

1/16/2019

Wag! adopted GitLab for their full CI/CD pipeline, encompassing application (API, Android, web) and infrastructure deployment. They integrated Terraform for infrastructure as code, enabling automated testing, review, staging, and deployment of infrastructure components. This resulted in a significant reduction in release process time from 40-60 minutes to 6 minutes. The post also highlights the integration of automated security scanning and license management into their CI/CD workflow.

12/6/2018

This post introduces a breaking change for SAST job definitions in Auto DevOps with GitLab 11.6, requiring GitLab Runner 11.5 or newer. This is due to the adoption of the `reports` syntax, which is necessary for displaying SAST results in the Group Security Dashboard. Runners prior to 11.5 will not support this syntax, causing SAST jobs to fail without blocking pipelines and preventing security reports from being generated. This change is a precursor to similar updates for Dependency Scanning, Container Scanning, DAST, and License Management.

10/31/2018

Introduced multi-project pipelines, enabling the triggering of downstream pipelines from upstream jobs using `$CI_JOB_TOKEN` and the Pipeline Trigger API. Enhanced pipeline graph visualization to display upstream and downstream stages. Enabled downloading artifacts from other projects via the Jobs API.

10/24/2018

This post details the setup of a basic `.gitlab-ci.yml` configuration for Android projects, including defining Docker images, variables, installing the Android SDK, and configuring build and test stages to ensure code compilation and passing unit/functional tests. It provides a concrete example for setting up CI for Android development within GitLab.

9/3/2018

This post provides a comparative analysis of GitLab CI against three variants of Jenkins (legacy, Cloud Native, and Evergreen). It highlights GitLab CI's strengths in extensibility, general-purpose use, community contribution, service stability (automatic restarts), brittle configuration avoidance (integrated codebase), assembly-free setup (convention over configuration), development velocity (monthly releases), Kubernetes integration (runners, ongoing exploration of CRDs), new extensibility mechanisms (following Knative), data management (object storage, database), configuration as code (via .gitlab-ci.yml), and secure-by-default design (remote agent execution).

8/9/2018

This post details the integration of DevOps and CI/CD practices into GitLab's frontend workflow. It highlights the move from the Rails asset pipeline to webpack for improved local development and debugging, and the use of GitLab Pages for automated publishing of assets like SVG libraries and Trello Power-Ups. The post also discusses the implementation of performance monitoring using Sitespeed and the adoption of Prettier for code formatting automation. It emphasizes the benefits of these changes in improving developer velocity, code consistency, and overall product quality.

8/2/2018

This post details how to use GitLab CI/CD to automate the testing and deployment of Home Assistant configurations. It covers setting up a Git repository for configuration backups, creating a CI/CD pipeline with stages for testing (using the Home Assistant Docker image and `hass --script check_config`), deployment (using SSH to pull changes and restart the Home Assistant Docker container), and optional notifications (using Pushover). It also outlines the necessary CI/CD variables and server preparation for SSH access.

7/23/2018

This post details Jaguar Land Rover's adoption of CI/CD to drastically reduce their software development lifecycle. Key technical changes include moving to ephemeral Docker containers for builds, defining build infrastructure as code using packer recipes, and implementing over-the-air software delivery to vehicles. This resulted in a reduction of feedback loops from 4-6 weeks to 30 minutes and enabled 50-70 deployments per day per individual piece of software in their engineering environment.

6/29/2018

This post details an experimental application of GitLab CI/CD to automate a physical process: cooking sous-vide egg bites. It describes setting up a Raspberry Pi with GitLab Runner to establish a Bluetooth Low Energy (BLE) connection to an Anova Sous Vide device. The pipeline is triggered via GitLab, demonstrating the integration of hardware control with CI/CD workflows.

6/21/2018

This post details a user's positive experience transitioning from Jenkins to GitLab CI/CD. The author highlights the improved visibility and ease of debugging provided by GitLab's pipeline, contrasting it with their previous struggles with Jenkins where they lacked visibility into problem origins. The author expresses a newfound 'love' for CI/CD due to this experience.

6/19/2018

This post details the technical implementation of autoscaling GitLab CI/CD on DigitalOcean. It covers the setup of a bastion server controlling GitLab Runner via Docker Machine, the creation of transient runner Droplets, and the use of DigitalOcean Spaces for caching. It also explains the terminology of GitLab, GitLab Bastion, and GitLab Runner in this context and provides step-by-step instructions for project import, infrastructure setup, and runner registration.

5/2/2018

This post details the automation of the daily merge of gitlab-ce into gitlab-ee using GitLab CI pipeline schedules. It describes the development of a script within the `release-tools` project to automate the merge process, handle conflicts by identifying responsible developers, create merge requests via the GitLab API, and post notifications to Slack. The implementation involved creating SSH keys, secret variables, a CI job, and a pipeline schedule that runs every three hours, resulting in 229 automatic merges and reduced developer frustration.

2/5/2018

This post introduces the concept of using Docker within GitLab CI/CD to automate testing for various application types. It provides example `.gitlab-ci.yml` configurations for Node.js, Django, and Unity3D projects, demonstrating how to leverage Docker images for consistent build and test environments. It also includes useful links to GitLab CI/CD documentation, linters, and example projects, as well as guidance on publishing Docker images to Docker Hub from GitLab CI.

1/17/2018

This post argues that daily builds are insufficient for true Continuous Integration and advocates for more frequent, ideally per-check-in, builds. It stresses the importance of running all unit and acceptance tests automatically with every build and highlights the need to immediately address build failures rather than ignoring them. The post emphasizes short feedback loops and the responsibility of craftsmen to use CI tools to their fullest extent for creating the best software.

11/27/2017

This post details the integration of Go's built-in testing tools (lint, unit tests, data race detection, memory sanitizer, code coverage) and build commands into a Makefile and subsequently into GitLab CI pipelines to automate the development workflow for Go projects. It covers the usage of `go list`, `golint`, `go test -short`, `go test -race`, `go test -msan`, `go test -covermode=count`, and `go build`. The Makefile targets and `.gitlab-ci.yml` configuration are provided as examples.

11/23/2017

This post details the implementation of an autoscaling GitLab CI/CD runner setup using docker-machine and AWS EC2 Spot Instances. It covers the creation of a spawner machine, installation of gitlab-runner and docker-machine, and configuration of the `config.toml` file to enable autoscaling. Key `MachineOptions` for AWS EC2, including VPC, region, instance type, and the use of `amazonec2-request-spot-instance=true` with `amazonec2-spot-price` to leverage cost savings from Spot Instances, are explained.

11/20/2017

This post details the configuration of `gitlab-ci.yml` for Android projects, outlining specific jobs for building APKs, running unit and instrumentation tests (including emulator setup and animation disabling), performing static analysis with lint, checkstyle, pmd, and findbugs, and manual deployment using Fastlane. It explains the use of `before_script`, `stages`, `artifacts`, and `when: manual` within the GitLab CI context for Android development.

11/14/2017

HumanGeo migrated from Jenkins to GitLab CI, reducing CI administration time from 5-6 hours/month to 10-15 minutes/month. They achieved approximately 1/3 cost savings by utilizing GitLab's flexible CI runners with autoscaling on spot instances for ~40 hours/week, compared to a dedicated m2.xlarge instance on AWS for Jenkins. The adoption of GitLab CI's YAML DSL for defining CI as code was highlighted as a significant ease-of-use improvement over Jenkins' Groovy.

11/2/2017

This post introduces the automation of Git operations within GitLab CI. It details how to configure CI jobs to automatically rebase a 'ts' branch onto the 'master' branch after a push to 'master'. It also describes a workflow for automatically creating merge requests when a NED (Network Element Driver) is updated, by modifying a version file in a separate repository and pushing the changes. The post provides specific `.gitlab-ci.yml` configurations for these automation tasks, including SSH key setup and Git commands.

9/27/2017

This post announces GitLab's recognition as a Leader in the Forrester Wave™ for Continuous Integration Tools, Q3 2017. It highlights GitLab's top scores in Current Offering and Strategy categories, emphasizing ease of installation, configuration, platform support, analytics, intuitive UI, and container support. It also introduces Auto DevOps as a new feature that automates the build, test, code quality assurance, review apps, deployment, and monitoring stages of the DevOps lifecycle, aiming for a hands-free DevOps experience. The post reiterates the importance of CI/CD for faster time-to-value and collaboration without dependency.

9/21/2017

This post details the evolution of a CI/CD pipeline using GitLab CI, Helm, and Kubernetes for auto-deployment. Key technical contributions include: migrating from docker-in-docker to using cache for packages, splitting CI jobs into multiple steps for better feedback, and implementing autodeploy to a staging environment using Helm charts. It provides specific examples of `.gitlab-ci.yml` configurations for building Golang images with caching, running tests with coverage reports, and deploying to Kubernetes using base64 encoded kubeconfig and Helm commands for installation and upgrades based on application versions.

9/4/2017

This post announces the deprecation and eventual removal of support for GitLab Runner versions prior to 9.0. It states that runners older than 9.0 will stop working with GitLab 10.0 due to the removal of an old API. Users are strongly encouraged to upgrade their runners to version 9.0 or newer before GitLab 10.0 is released on September 22nd, with RC deployment around September 8th. Instructions are provided on how to check for old runners and how to upgrade them.

8/25/2017

This post introduces the concept of research reproducibility and details how GitLab's CI/CD features, specifically its integrated Docker Container Registry and support for external registries, can be used to achieve it. It explains how `.gitlab-ci.yml` files can define pipelines that execute research workflows within isolated Docker containers, providing concrete examples for R package building and static website generation with Nikola. The post also mentions the ability to use different containers per job step and trigger multi-project pipelines, as well as the automatic provisioning of VMs for large data processing.

8/14/2017

This post details the initial implementation of containerizing a client application using Docker and integrating it with GitLab CI for automated building and deployment to Docker Swarm. It includes the use of a RHEL 6.9 base image, layering dependencies and the application, configuring Docker Swarm for automated updates with minimal downtime, and implementing security scanning with Brakeman, Red Hat's atomic scanner, and Arachni. The post also highlights the benefits of this DevOps approach, such as improved collaboration between Ops and Dev teams, faster time to delivery, lower failure rates, and simplified application recovery.

8/7/2017

This post details the use of GitLab and GitLab CI for Git and continuous integration. It highlights the use of webhooks to trigger notifications in Matrix rooms based on Git events and pipeline statuses. It also covers monitoring GitLab server internals using Prometheus and Grafana. The authors chose GitLab for its integrated issue tracker, snippets area, open API, and webhook capabilities. They also mention using the official GitLab Docker image which includes Prometheus for monitoring, and plotting this data in a Grafana dashboard.

7/27/2017

This post details the migration of a Jenkins CI job to GitLab CI, specifically highlighting the use of Docker to manage dependencies and external services. It contrasts the verbose and machine-dependent configuration of Jenkins with the streamlined `.gitlab-ci.yml` approach enabled by Docker. Key technical contributions include: defining a custom Docker image for PHP dependencies, using Docker services to orchestrate MongoDB, and simplifying test execution by isolating the environment. The post also demonstrates how to run GitLab CI jobs locally using GitLab Runner.

7/18/2017

This post details the Province of Nova Scotia's implementation of GitLab CI for their Puppet code deployment workflow. It describes their automated testing strategy, including syntax checking, linting, unit, and integration tests (using ServerSpec and test-kitchen). Each test job is run in an isolated Docker container. The post also outlines their continuous deployment process, involving merge requests for peer review and subsequent deployment to Red Hat Satellite and Puppet Enterprise servers upon approval. Configuration files for Docker, test-kitchen, .gitlab-ci.yml, and the Satellite push script are made available on GitHub.

7/13/2017

This post introduces the fundamental concepts of GitLab CI/CD, including `.gitlab-ci.yml` structure, jobs, stages, variables, and flow control mechanisms (`only`, `except`, `when`). It also demonstrates how to create reusable CI/CD templates using YAML anchors and references to manage deployments across different environments (production, staging) and regions, emphasizing DRY principles and variable-driven configuration.

7/11/2017

This post details the technical implementation of Dockerizing GitLab Review Apps. It outlines the .gitlab-ci.yml configuration for build and deploy stages, including Docker image creation, tagging with branch names, pushing to a private registry, and deploying containers using Docker run commands with Traefik labels for routing. It also addresses the manual Docker login requirement for the runner and the use of self-signed SSL certificates for Traefik in an intranet environment.

6/7/2017

This post details Ticketmaster's migration from a slow Jenkins CI pipeline to GitLab CI for their Android and iOS mobile app development. The primary technical challenge addressed was the significant build time reduction from 2 hours on Jenkins to under 8 minutes with GitLab CI. This was achieved by leveraging GitLab CI's capabilities, including integration with Amazon ECR for Docker container registry, and enabling faster build, test, and artifact generation. The post highlights the technical details of pushing Docker images to ECR and pulling them for builds, and the use of Gradle and SonarQube for code quality analysis within the CI pipeline. The success of this migration enabled Ticketmaster to achieve weekly mobile releases, improving fan experience and product quality.

5/22/2017

This post introduces the core concepts of GitLab CI/CD, including its YAML configuration file, the role of runners in executing build scripts, secrets management for authorization tokens, the concept of pipelines as a sequence of steps from source code to deployment, the container registry for storing Docker images, and environments/review apps for dynamic per-branch deployments. It highlights the advantages of a tightly coupled CI/VCS system, versioned CI configuration, out-of-the-box Docker integration, an artifacts browser, and reduced maintenance overhead for CI servers. It also discusses potential drawbacks such as a 'convention over configuration' model and fewer plugin integrations compared to other CI tools.

5/8/2017

This post introduces the core considerations for selecting a CI/CD tool, including hosting options (SaaS vs. on-premise), licensing models (open source vs. commercial), the importance of integrations with other development tools (like issue boards), and the value of visualizing the release process (e.g., with Review Apps and Deploy Boards). It then maps these considerations to GitLab's offerings, highlighting its self-managed and hosted options, free and enterprise editions, and built-in visualization features like CI/CD Pipelines, Review Apps, and Prometheus monitoring.

4/12/2017

This post introduces the fundamental benefits of CI/CD: saving time via automation, saving money by early issue detection, and minimizing downtime through frequent integration. It mentions leveraging tools like Docker and Kubernetes for cloud power and running tests across multiple environments. It also references a webcast on 'From Continuous Integration to Continuous Everything'.

2/22/2017

This post from 2017 highlights the growing importance of continuous integration (CI) for developers, noting that over 75% of developers use CI tools regularly and 77% consider them essential. It emphasizes that CI automates testing, freeing up developer time for feature development and reducing the risk of shipping untested code. The post also touches on the broader adoption of continuous methods beyond development teams.

12/14/2016

This post details the integration of Spring Boot applications with GitLab CI and Kubernetes for automated build, test, and deployment pipelines. It covers creating a GitLab project, bootstrapping a Spring Boot application using Maven and Actuator, packaging the application as a Docker container with a Dockerfile, defining the Kubernetes deployment using a YAML file, and configuring the `.gitlab-ci.yml` file to automate the build, test, and deployment process. It also introduces the concepts of Spring Boot, Kubernetes, and the GitLab Flow.

11/27/2016

This post details a team lead's experience and recommendation of GitLab, specifically highlighting its integrated CI/CD capabilities. The author discusses using GitLab for personal and professional projects, migrating a team from Subversion to Git and GitLab, and counseling others to switch. Key technical points include the benefits of decentralized Git/GitLab for distributed teams, the importance of short-lived merge requests for efficient code reviews, and the primary barrier to GitLab CI adoption being training and ingrained habits. The author also contrasts GitLab with other tools like GitHub and Bitbucket, emphasizing GitLab's open-source nature, integration of features (version control, bug tracker, kanban board, MR handling, CI), and self-hosting capabilities. The post also touches on the challenges of migrating large Subversion monorepos to Git and suggests GitLab could provide educational resources for such transitions.

10/17/2016

This post details OOHLALA Mobile's decision to adopt GitLab CI for their CI/CD solution. They highlight the simplicity of GitLab CI's shell executor for executing existing Fabric scripts, its speed due to the ability to pre-install dependencies on custom runners, and its cost-effectiveness compared to other CI/CD platforms. The ability to install runners on dedicated macOS and Windows machines for mobile CI/CD was a key factor. They also note the security benefit of keeping SSH private keys within their own infrastructure.

10/12/2016

This post details the technical implementation of automating Debian package builds using GitLab CI and Docker. It outlines the steps for preparing Debian package control files (`debian/changelog`, `debian/compat`, `debian/control`, `debian/rules`), creating a generic Docker container with necessary build tools (`git`, `dh-make`, `build-essential`, `autoconf`, `autotools-dev`), and configuring `.gitlab-ci.yml` to execute the build process (`apt-get install`, `autoreconf`, `dpkg-buildpackage`). It also describes the workflow of triggering builds via Git tags and making artifacts available for download. The outlook suggests further automation by uploading built packages to a mirror and publishing them via an Aptly repository.

8/11/2016

This post details the implementation of a CI/CD pipeline for building Elixir releases into Docker images. It outlines the `.gitlab-ci.yml` configuration, including stages for build, styles, test, release, and cleanup. Specific technical details include the use of `docker:latest` image, custom Dockerfiles (`Dockerfile.build` and `Dockerfile`), volume management for build artifacts, manual linking of services like PostgreSQL, and the process of building and pushing the release image to the GitLab Container Registry. It also touches upon using environment variables for configuration and the `mix release` command for creating the Elixir release artifact.

8/5/2016

This post introduces and explains the concepts of Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment (CDP) and how GitLab's CI/CD features support these practices. It details the automated build, test, and deployment pipeline, including manual actions for deployment and rollback, and the ability to deploy to staging and production environments. The post also mentions the integration with Docker Cloud for deployments and the tracking of the entire development process within GitLab.

7/22/2016

This post details Captain Train's migration from Jenkins to GitLab CI for their web-app builds. Key technical contributions include: 1. Insulating builds into Docker containers for isolation, cross-architecture support, and greater control over build environments. 2. Demonstrating the scalability of GitLab CI by easily adding new runners and automatic runner selection. 3. Highlighting the ease of control and versioning provided by `.gitlab-ci.yml` files compared to Jenkins' external configuration. 4. Implementing tests on merge requests for improved stability and reduced build breakage. 5. Showcasing the 'Pipelines' UI for build overviews.

6/21/2016

This post details the integration of Docker into GitLab's CI/CD capabilities. It introduces the Docker executor for GitLab CI Runners, enabling isolated and clean build environments. It also covers autoscaling CI Runners using Docker Machine to dynamically provision and de-provision build instances, optimizing resource usage and reducing wait times for tests. Furthermore, it highlights the integration of the GitLab Container Registry for storing and managing Docker images, simplifying development and deployment workflows. The post quantifies the impact of these changes on test execution times, reducing wait times from 10 minutes to seconds, and discusses the ongoing migration of Omnibus package builds to Docker for improved scalability and concurrency.

5/5/2016

This post details the integration of Shippable CI/CD with GitLab. It outlines the steps for setting up the integration by adding a GitLab integration in Shippable, providing the GitLab API endpoint and a private token. It also explains how Shippable automatically triggers builds for commits and merge requests and displays the build status within GitLab. The post also mentions configuring continuous delivery using Shippable Pipelines and Docker.

4/19/2016

This post announces a partnership with DigitalOcean to address scaling challenges in CI. It introduces the GitLab Runner Autoscale feature, which dynamically spins up and down instances to meet build demands, making CI faster, safer, and more affordable. The post highlights the benefits of this autoscaling for developers, including improved speed, security through ephemeral environments, and cost savings. It also details promotional offers for free Runners and discount codes for DigitalOcean accounts for GitLab.com, CE, and EE users.

4/5/2016

This post announces the introduction of autoscaling for GitLab.com Shared Runners, powered by GitLab Runner 1.1. This feature aims to reduce build queue times and machine allocation times. The autoscaling configuration uses the `docker+machine` executor, provisioned on Digital Ocean 4GB instances with CoreOS and Docker. Key aspects of the autoscaling setup include distributed caching, a Docker registry mirror, and a security focus on using fresh machines for each build. The post also details changes to the default services available to runners, removing pre-configured databases and requiring explicit declaration in `.gitlab-ci.yml`.

3/28/2016

This post announces a live tutorial and webcast to educate users on GitLab CI, emphasizing its integrated nature since GitLab 8.0. It highlights key features and benefits such as multi-platform/language support, real-time logging, and versioned tests via .gitlab-ci.yml, and its Continuous Delivery capabilities. It also addresses common questions about its availability and cost.

3/14/2016

This post highlights the integration of GitLab CI as a core feature, emphasizing its embedded nature within GitLab, contrasting with separate CI services. It introduces the concept of 'runners' as the mechanism for executing CI jobs, explaining their role in running tests and builds. The post also mentions the availability of 'Shared Runners' on GitLab.com and the option for users to set up their own runners for better performance. Additionally, it introduces GitLab Pages as a feature powered by CI for hosting static websites, and the 'Merge when build succeeds' option, further demonstrating the practical application of CI in streamlining development workflows.

3/10/2016

This post details the step-by-step process of setting up GitLab CI for iOS projects. It covers creating an Xcode project with unit and UI tests, sharing the Xcode scheme, setting up a `.gitignore` file, installing and registering a GitLab Runner on macOS with specific tags for toolchain and platform, and configuring the `.gitlab-ci.yml` file to use `xcodebuild` and `xcpretty` for cleaning, building, and testing iOS applications. It also highlights the importance of the `-destination` flag for specifying the simulator and OS version.

3/1/2016

This post details the setup and configuration of GitLab Runner with its Docker executor for continuous integration. It covers creating a `.gitlab-ci.yml` file to define build environments and scripts, including the use of Docker images and services for dependencies like PostgreSQL. It also explains how to use shared runners and how to install and register a specific runner on a private server. Furthermore, it introduces caching for `node_modules` to speed up builds and demonstrates how to add concurrency by splitting tests into multiple jobs and increasing the runner's concurrent setting.

12/14/2015

This post introduces the fundamental concepts of Continuous Integration (CI) and Continuous Delivery (CD) in the context of modern agile software development. It explains how GitLab CI is integrated directly into GitLab, eliminating the need for separate applications. The post details the role of the `.gitlab-ci.yml` file for defining build processes and introduces GitLab Runner as the component responsible for executing these builds. Key features of GitLab Runner, such as its open-source nature, cross-platform compatibility, and support for various execution environments (Docker, SSH), are highlighted. Future planned features like passing CI build artifacts between stages, a GitLab container registry, and GitLab Deploy are also mentioned.

8/19/2015

This post details the integration of GitLab projects with Quay.io for automated Docker container image building on every push to source control. It provides a step-by-step guide on setting up build triggers in Quay.io to link with GitLab repositories, including authorization and repository selection. The integration ensures that developers have up-to-date container images available quickly after code changes.

6/8/2015

This post details the technical implementation of migrating GitLab CI jobs from a UI-based definition to a `.gitlab-ci.yml` file. It explains the schema change where GitLab now sends the `.gitlab-ci.yml` content along with the webhook to the CI Coordinator. It also outlines the migration strategy, including automatic conversion of existing UI-defined jobs to YAML and the process for users to adopt the new style by copy-pasting the generated YAML file. An example `.gitlab-ci.yml` for a Ruby on Rails project is provided, along with an updated proposal for the file syntax.

5/6/2015

Introduced `.gitlab-ci.yml` as a replacement for form-based GitLab CI job configuration. This enables version control of build scripts, allows builds for older versions of code, improves handling of forks, facilitates branch-specific builds, provides a single source of truth for build configurations accessible to all with read access, and enables build matrices. This change is a breaking change and will be introduced with GitLab 8.0.

5/3/2015

This post announces the deprecation of the Ruby-based GitLab CI runner and the official adoption of the Go-based runner. It provides migration guidance, installation instructions for various platforms (Debian/Ubuntu/CentOS/RedHat, macOS, Windows, Docker), and usage instructions for the new runner. It also highlights the benefits of the new runner, such as multiple concurrent jobs and Docker support.

4/17/2015

Introduced the unofficial GitLab CI Multi-purpose Runner, written in Go, to address limitations of the official Ruby-based runner. Key improvements include support for multiple concurrent jobs, virtualization (Docker, Parallels), cross-platform compatibility (Linux, macOS, Windows), and easier service setup. The runner can be installed via packages, macOS/Windows installers, or as a Docker service, and supports various executors including local, Docker, SSH, and Parallels VMs. It also features caching for Docker containers and automatic configuration reload.

2/3/2015

This post outlines the fundamental benefits of Continuous Integration (CI) for software development. It details seven key reasons to adopt CI: running tests in a real-world environment to catch discrepancies, increasing code coverage by highlighting untested code, enabling continuous deployment to production, automating build and compilation processes, accelerating builds through parallelization, preventing regressions by testing before merging, and decreasing code review time by providing merge readiness indicators. It also promotes GitLab CI as a solution that incorporates these features.

1/29/2015

This post introduces the capability for parallel test execution in GitLab CI by leveraging multiple workers (runners). It highlights the cost-effectiveness of self-hosting runners compared to commercial CI providers for achieving parallel builds. It also details the free CI hosting on ci.gitlab.com and provides information on claiming cloud credits from Google Cloud Platform and Digital Ocean to facilitate runner setup.

11/6/2014

This post announces the inclusion of the GitLab CI Coordinator within the GitLab Omnibus packages. It details the steps required to enable and configure GitLab CI on an existing GitLab server, including DNS setup and configuration file modifications. It also highlights the minimal increase in package size due to component reuse and the RAM requirements for running the CI Coordinator.

6/20/2013

This post introduces the integration of GitLab CI with GitLab, enabling distributed builds by default. It outlines the benefits of this integration, including single sign-on with GitLab credentials, UI integration showing accessible projects, and simplified setup. The architecture is described as a clean separation using GitLab's public API, with GitLab CI as a rack application. A key concept introduced is the split into coordinators and runners, where runners perform builds on separate machines to avoid security risks associated with running tests on the source code server. This design aims to encourage best practices for CI/CD.