<!-- PkgPulse AI-readable guide source -->
<!-- Canonical: https://www.pkgpulse.com/guides/github-actions-vs-circleci-vs-gitlab-ci-cicd-platforms-2026 -->
<!-- Raw Markdown: https://www.pkgpulse.com/guides/github-actions-vs-circleci-vs-gitlab-ci-cicd-platforms-2026/raw.md -->
<!-- Source path: content/guides/github-actions-vs-circleci-vs-gitlab-ci-cicd-platforms-2026.mdx -->

---
og_image: "/images/guides/github-actions-vs-circleci-vs-gitlab-ci-cicd-platforms-2026.webp"
title: "GitHub Actions vs CircleCI vs GitLab CI 2026"
description: "Compare GitHub Actions, CircleCI, and GitLab CI for CI/CD in 2026—plus when Semaphore is worth shortlisting for pricing, self-hosting, and AI workflows."
date: "2026-03-09"
author: "PkgPulse Team"
tags: ["javascript", "typescript", "devops", "ci-cd"]
tier: 2
---

## TL;DR

**GitHub Actions** is the CI/CD built into GitHub — YAML workflows, marketplace with 20K+ actions, matrix builds, integrated with Issues/PRs, free for public repos. **CircleCI** is the performance-focused CI/CD — fast builds, advanced caching, orbs (reusable packages), Docker layer caching, SSH debugging. **GitLab CI** is the all-in-one DevOps CI/CD — built into GitLab, Auto DevOps, container registry, security scanning, the most complete built-in DevOps pipeline. **Semaphore** is a credible fourth option when pricing, open-source self-hosting, or AI-agent/MCP access to CI activity matters, but it does not replace the core three-way search intent. In 2026: GitHub Actions for GitHub-hosted projects, CircleCI for performance-critical pipelines, GitLab CI for full DevOps lifecycle, and Semaphore for cost-conscious or AI-native teams willing to run their own benchmark.

## Key Takeaways

- **GitHub Actions**: Most popular — 20K+ marketplace actions, free for public repos
- **CircleCI**: Fastest builds — advanced caching, Docker layer caching, SSH debug
- **GitLab CI**: Most complete — built-in registry, security scanning, Auto DevOps
- **Semaphore**: Worth shortlisting — open-source Community Edition, published pay-as-you-go compute pricing, and MCP/AI-agent workflow hooks
- GitHub Actions has the largest ecosystem of reusable actions
- CircleCI has the best caching and parallel execution
- GitLab CI includes features others charge for (SAST, DAST, container scanning)

---

## Quick Comparison

| | GitHub Actions | CircleCI | GitLab CI |
|---|---|---|---|
| Free tier | 2,000 min/month | 6,000 credits/month | 400 min/month |
| Self-hosted runners | ✅ | ✅ | ✅ |
| Docker support | ✅ | ✅ (first class) | ✅ |
| Marketplace/Orbs | 20K+ actions | 1K+ orbs | Templates |
| Native VCS | GitHub | Any | GitLab |
| ARM support | ✅ | ✅ | ✅ |
| Approval gates | ✅ | ✅ | ✅ |
| OIDC/OIDC tokens | ✅ | ✅ | ✅ |

---

## GitHub Actions

[GitHub Actions](https://github.com/features/actions) — CI/CD for GitHub:

### Basic Node.js workflow

```yaml
# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "pnpm"

      - run: pnpm install --frozen-lockfile
      - run: pnpm run lint
      - run: pnpm run typecheck
      - run: pnpm run test --coverage

      - uses: actions/upload-artifact@v4
        if: matrix.node-version == 20
        with:
          name: coverage
          path: coverage/

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "pnpm"
      - run: pnpm install --frozen-lockfile
      - run: pnpm run build
```

### Deploy workflow

```yaml
# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      deployments: write

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "pnpm"

      - run: pnpm install --frozen-lockfile
      - run: pnpm run build

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          command: pages deploy dist --project-name=pkgpulse
```

### Reusable workflows

```yaml
# .github/workflows/reusable-test.yml
name: Reusable Test

on:
  workflow_call:
    inputs:
      node-version:
        required: false
        type: string
        default: "20"

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: "pnpm"
      - run: pnpm install --frozen-lockfile
      - run: pnpm test

# Usage in another workflow:
# jobs:
#   call-tests:
#     uses: ./.github/workflows/reusable-test.yml
#     with:
#       node-version: "22"
```

---

## CircleCI

[CircleCI](https://circleci.com) — performance-focused CI/CD:

### Basic config

```yaml
# .circleci/config.yml
version: 2.1

orbs:
  node: circleci/node@5.2

executors:
  node-executor:
    docker:
      - image: cimg/node:20.11
    resource_class: medium

jobs:
  test:
    executor: node-executor
    parallelism: 4
    steps:
      - checkout
      - node/install-packages:
          pkg-manager: pnpm
      - run:
          name: Lint
          command: pnpm run lint
      - run:
          name: Type Check
          command: pnpm run typecheck
      - run:
          name: Test (parallel)
          command: |
            TESTS=$(circleci tests glob "tests/**/*.test.ts" | circleci tests split --split-by=timings)
            pnpm run test $TESTS
      - store_test_results:
          path: test-results
      - store_artifacts:
          path: coverage

  build:
    executor: node-executor
    steps:
      - checkout
      - node/install-packages:
          pkg-manager: pnpm
      - run: pnpm run build
      - persist_to_workspace:
          root: .
          paths: [dist]

  deploy:
    executor: node-executor
    steps:
      - attach_workspace:
          at: .
      - run:
          name: Deploy
          command: npx wrangler pages deploy dist

workflows:
  ci-cd:
    jobs:
      - test
      - build:
          requires: [test]
      - deploy:
          requires: [build]
          filters:
            branches:
              only: main
```

### Advanced caching

```yaml
jobs:
  test:
    executor: node-executor
    steps:
      - checkout

      # Restore multiple caches:
      - restore_cache:
          keys:
            - deps-v1-{{ checksum "pnpm-lock.yaml" }}
            - deps-v1-

      - run: pnpm install --frozen-lockfile

      - save_cache:
          key: deps-v1-{{ checksum "pnpm-lock.yaml" }}
          paths:
            - node_modules
            - ~/.pnpm-store

      # Docker layer caching (paid feature):
      - setup_remote_docker:
          docker_layer_caching: true

      - run: docker build -t pkgpulse .
```

### Orbs (reusable packages)

```yaml
version: 2.1

orbs:
  node: circleci/node@5.2
  aws-cli: circleci/aws-cli@4.1
  slack: circleci/slack@4.12

jobs:
  deploy:
    executor: node-executor
    steps:
      - checkout
      - node/install-packages:
          pkg-manager: pnpm
      - run: pnpm run build
      - aws-cli/setup
      - run:
          name: Deploy to S3
          command: aws s3 sync dist/ s3://pkgpulse-prod/
      - slack/notify:
          event: pass
          template: basic_success_1
```

---

## GitLab CI

[GitLab CI](https://docs.gitlab.com/ee/ci/) — all-in-one DevOps CI/CD:

### Basic pipeline

```yaml
# .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"

default:
  image: node:${NODE_VERSION}
  cache:
    key:
      files:
        - pnpm-lock.yaml
    paths:
      - node_modules/
      - .pnpm-store/

test:
  stage: test
  script:
    - corepack enable
    - pnpm install --frozen-lockfile
    - pnpm run lint
    - pnpm run typecheck
    - pnpm run test --coverage
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
      junit: test-results/junit.xml

build:
  stage: build
  script:
    - corepack enable
    - pnpm install --frozen-lockfile
    - pnpm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

deploy:
  stage: deploy
  script:
    - npx wrangler pages deploy dist
  environment:
    name: production
    url: https://pkgpulse.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
```

### Security scanning

```yaml
# Built-in security scanning:
include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml

# These run automatically:
# - SAST: Static Application Security Testing
# - Dependency scanning: Check npm for vulnerabilities
# - Secret detection: Find leaked secrets
# - Container scanning: Scan Docker images
```

### Multi-environment

```yaml
stages:
  - test
  - build
  - deploy-staging
  - deploy-production

deploy-staging:
  stage: deploy-staging
  script:
    - npx wrangler pages deploy dist --branch staging
  environment:
    name: staging
    url: https://staging.pkgpulse.com
  rules:
    - if: $CI_MERGE_REQUEST_ID

deploy-production:
  stage: deploy-production
  script:
    - npx wrangler pages deploy dist
  environment:
    name: production
    url: https://pkgpulse.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  when: manual  # Require manual approval
```

### Child pipelines and includes

```yaml
# .gitlab-ci.yml
include:
  - local: .gitlab/ci/test.yml
  - local: .gitlab/ci/build.yml
  - local: .gitlab/ci/deploy.yml
  - project: 'shared/ci-templates'
    ref: main
    file: '/templates/node-pipeline.yml'

# Dynamic child pipelines:
generate-pipeline:
  stage: prepare
  script:
    - node scripts/generate-ci.js > child-pipeline.yml
  artifacts:
    paths:
      - child-pipeline.yml

run-dynamic:
  stage: test
  trigger:
    include:
      - artifact: child-pipeline.yml
        job: generate-pipeline
```

---

## Cost Breakdown for Real Workloads

Pricing models differ significantly and the "cheapest" option depends heavily on your usage pattern:

**GitHub Actions free tier math:**
- 2,000 Linux minutes/month free for private repos (public repos are unlimited)
- At 10 min/build × 100 builds/day = 1,000 min/day — you'd burn through the free tier in 2 days
- $0.008/min for Linux after free tier
- Self-hosted runners: free (you pay for the compute, not GitHub)
- Storage: 500 MB artifact free, then $0.25/GB/month

**CircleCI free tier math:**
- 6,000 credits/month free (1 credit ≈ 1 CPU-second at medium resource class)
- A medium Docker executor runs at 10 credits/minute
- 6,000 credits = 600 minutes — comparable to GitHub's 2,000 minutes for medium workloads
- Performance/Large executors burn credits faster but run jobs faster (net similar cost)
- Self-hosted runners available on all paid plans

**GitLab CI free tier math:**
- 400 CI/CD minutes/month on GitLab.com free tier — the most restrictive
- Unlimited for self-managed GitLab instances
- GitLab Dedicated starts at $99/month for managed instances
- Most teams using GitLab at scale self-host to avoid minute limits

**Self-hosted runners change the math entirely.** If you have spare compute (cloud VMs, on-prem servers, spare Macs for iOS builds), all three platforms let you run unlimited minutes on self-hosted runners for free. This is how large engineering teams use all three platforms: connect their own infrastructure and only use hosted runners for burst capacity.

---

## Ecosystem Integration & Secrets Management

**GitHub Actions marketplace:** 20,000+ community actions covering every major cloud provider, testing framework, deployment target, and developer tool. The density of ready-made actions means most workflows are composed, not written. Need to deploy to AWS? `aws-actions/configure-aws-credentials`. Need to publish to npm? `actions/setup-node` + `npm publish`. The ecosystem effect compounds — GitHub Actions benefits from GitHub being the primary code host.

**CircleCI Orbs:** CircleCI's reusable config components (~1,000+ orbs) let you import pre-built job configurations. Orbs are more tightly integrated than Actions (they can modify the executor environment, inject steps), but the catalog is smaller. CircleCI's strength is pipelines that require precise resource class control: running tests in high-CPU Docker containers, then deploying from a separate arm executor, with approval gates between stages.

**GitLab CI templates and includes:** GitLab CI uses `.gitlab-ci.yml` with `include:` to pull in shared templates. GitLab ships auto DevOps templates for common stacks (Node.js, Docker, Kubernetes). For teams using GitLab's full suite (issues, MR reviews, container registry, Kubernetes integration, security scanning), the tightest workflow integration is within GitLab itself.

**Secrets management:**
- All three support encrypted environment variables
- GitHub Actions: native Secrets + OIDC tokens for zero-secret cloud auth (AWS, GCP, Azure)
- CircleCI: Contexts for shared secrets across projects, orgs
- GitLab CI: Group-level variables propagate to all child projects

OIDC-based auth (no stored cloud credentials) is now the recommended approach for cloud deployments on all three platforms.

---

## Platform Deep Dives

### GitHub Actions in Practice

GitHub Actions launched in 2019 and has since become the dominant CI/CD platform for open-source projects, largely by virtue of its native integration with the place most code already lives. Every GitHub repository gets workflows for free — no additional account setup, no third-party credentials to configure, no separate dashboard to check. The `GITHUB_TOKEN` provided automatically to every run eliminates an entire category of secrets management for operations like creating releases, commenting on pull requests, or publishing to the GitHub Container Registry.

The matrix strategy is one of the most-used GitHub Actions features. Testing across multiple Node.js versions, operating systems, or configuration permutations requires just a few lines of YAML and fans out to parallel jobs automatically. For library maintainers who need to verify compatibility across environments, this alone justifies the platform.

Reusable workflows let organizations consolidate CI logic: define a test workflow once, call it from every repository's workflow file. Combined with the marketplace (20,000+ community actions), most teams find they can build sophisticated pipelines entirely by composing existing actions rather than writing shell scripts. The action versioning model — pin by commit SHA for security, pin by tag for convenience — gives teams control over when they adopt upstream changes.

### CircleCI in Practice

CircleCI's core differentiation has always been performance and debuggability. Its test splitting feature divides your test suite across parallel containers based on historical timing data — the system learns which tests are slow and distributes work to minimize total wall-clock time. Teams with large test suites (5,000+ tests) can see dramatic build time reductions from parallelism configured through a single `parallelism: N` key.

The SSH debug capability is genuinely unique. When a build fails in an environment-specific way (works locally, fails on CI), CircleCI lets you SSH directly into the exact container that ran the failing build, with all the same environment variables and filesystem state. This interactive debugging workflow saves hours on hard-to-reproduce failures.

CircleCI's resource classes give precise control over the compute allocated to each job: small, medium, large, xlarge, and arm equivalents. This matters when you have jobs with different resource profiles — a test runner that benefits from more CPU, a Docker build that needs more memory, a deployment job that needs only minimal resources. GitHub Actions offers a more coarse-grained selection (ubuntu-latest, larger GitHub-hosted runners on paid plans).

### GitLab CI in Practice

GitLab CI is inseparable from the GitLab platform itself. Its deepest advantage is available to teams running GitLab as their complete DevOps platform: merge request pipelines run on MR creation, deployment environments track which code is where, the built-in container registry stores Docker images without a separate service, and security scanning results surface directly in merge request views. The Auto DevOps feature can infer a reasonable pipeline for common project types without any `.gitlab-ci.yml` configuration at all.

The security scanning templates deserve particular mention. SAST, DAST, dependency scanning, secret detection, and container scanning are all available as GitLab-maintained templates — include a line in your pipeline and they run automatically, publishing results to the security dashboard. For organizations with compliance requirements, this turns security scanning from a separate tooling integration project into a configuration line.

GitLab's runner architecture is the most flexible of the three: runners can be registered at the project, group, or instance level, and the same runner can handle jobs from multiple projects with appropriate access controls. This centralized runner management is particularly useful for platform teams managing CI infrastructure across dozens of internal projects.

### Choosing Based on Your Current Tooling

The most pragmatic factor in choosing a CI/CD platform is often where your code already lives. Teams on GitHub rarely have a compelling reason to use an external CI service given how deeply GitHub Actions integrates with repository events, pull request status checks, release workflows, and the `GITHUB_TOKEN` permission model. Teams on GitLab similarly get the most value by staying within the GitLab ecosystem and taking advantage of its built-in DevSecOps features.

CircleCI occupies a different position: it's the platform you choose on its merits rather than because of where your code lives. Teams that migrated to CircleCI from Jenkins or Travis CI, or that built sophisticated pipelines around CircleCI's advanced parallelism and resource class controls before GitHub Actions existed, often find the switching cost uncompelling. CircleCI's SSH debugging, test splitting, and Docker layer caching remain genuine technical advantages for large-scale CI workloads.

### Where Semaphore Fits

[Semaphore](https://semaphore.io) is worth evaluating as a fourth shortlist candidate, especially if you are comparing CI/CD platforms because of cost, self-hosting, or AI-assisted build triage rather than because you are locked into a source-control host. Its published pricing separates compute from support services and lists $15 of free credits per month, pay-as-you-go Linux, macOS, and self-hosted-agent pricing, plus 20 concurrent jobs by default. Treat Semaphore's benchmark claims as vendor-supplied evidence, not as a universal result: run the same repository, cache strategy, and test suite across candidates before switching.

The self-hosting angle is also different from CircleCI's hosted-performance story. Semaphore's docs describe a production-ready [Community Edition](https://docs.semaphore.io/getting-started/install) that is open source under Apache-2.0 and free forever, with Enterprise Edition adding advanced workflows, audit logs, and advanced RBAC. That makes Semaphore more interesting for small platform teams that want a self-hostable CI/CD control plane than for teams that simply want the largest public ecosystem.

The newer AI workflow is the third differentiator. Semaphore's [MCP Server docs](https://docs.semaphore.io/using-semaphore/ai/mcp-server) expose organizations, projects, workflows, pipelines, jobs, logs, and test results to AI agents, with optional write permissions for scheduling or rerunning workflows. If your team is building agentic failure triage around CI logs and test reports, this is a real reason to include Semaphore in a proof of concept. If you only need default GitHub pull-request checks or GitLab-native DevSecOps, the primary three options above still match the dominant search intent better.

---

## Feature Comparison

| Feature | GitHub Actions | CircleCI | GitLab CI |
|---------|--------------|----------|----------|
| Built into | GitHub | Standalone | GitLab |
| Config format | YAML | YAML | YAML |
| Marketplace/Orbs | 20K+ actions | 3K+ orbs | Templates |
| Matrix builds | ✅ | ✅ | ✅ (parallel) |
| Parallel tests | ✅ (matrix) | ✅ (split by timing) | ✅ (parallel keyword) |
| Caching | ✅ (actions/cache) | ✅ (advanced) | ✅ |
| Docker layer cache | ❌ | ✅ (paid) | ✅ |
| SSH debugging | ❌ | ✅ | ❌ |
| Self-hosted runners | ✅ | ✅ | ✅ |
| Security scanning | ✅ (marketplace) | ✅ (orbs) | ✅ (built-in SAST/DAST) |
| Container registry | ✅ (GHCR) | ❌ | ✅ (built-in) |
| Environments | ✅ | ✅ | ✅ |
| Manual approvals | ✅ | ✅ | ✅ |
| Reusable workflows | ✅ | ✅ (orbs) | ✅ (includes) |
| Free tier | 2K min/month | 6K credits/month | 400 min/month |

---

## When to Use Each

**Use GitHub Actions if:**
- Your code is on GitHub (tightest integration)
- Want the largest marketplace of reusable actions
- Building open-source projects (free unlimited minutes)
- Need simple-to-complex workflows with YAML

**Use CircleCI if:**
- Need the fastest CI/CD builds with advanced caching
- Want test splitting by timing for parallel execution
- Need SSH debugging into failed builds
- Building performance-critical pipelines

**Use GitLab CI if:**
- Using GitLab for source control
- Want built-in security scanning (SAST, DAST, dependency)
- Need a complete DevOps platform (CI + registry + monitoring)
- Want Auto DevOps for convention-based pipelines

**Use Semaphore if:**
- You want hosted CI/CD pricing that is easy to model per minute and per job
- You want an open-source Community Edition or a hybrid/self-hosted deployment path
- You are experimenting with AI-agent CI triage through MCP access to workflows, logs, and test results
- You are willing to validate vendor benchmark claims against your own repository before migrating

---

## Migration Guide

### From CircleCI to GitHub Actions

CircleCI's `config.yml` concepts map directly to GitHub Actions, though the YAML structure differs:

```yaml
# CircleCI (old)
version: 2.1
jobs:
  test:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - run: pnpm install
      - run: pnpm test
workflows:
  main:
    jobs:
      - test

# GitHub Actions (equivalent)
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20" }
      - run: pnpm install
      - run: pnpm test
```

The main conceptual shifts: CircleCI `orbs` become GitHub Actions `uses` references, CircleCI `workflows` become GitHub Actions `jobs` with `needs` dependencies, and CircleCI `persist_to_workspace`/`attach_workspace` becomes `actions/upload-artifact`/`actions/download-artifact`.

### Migrating secrets and environment variables

All three platforms support repository-level secrets with similar semantics:

```yaml
# GitHub Actions — ${{ secrets.TOKEN }}
- run: npx wrangler deploy
  env:
    CLOUDFLARE_API_TOKEN: ${{ secrets.CF_TOKEN }}

# CircleCI — $TOKEN from project environment variables
- run:
    command: npx wrangler deploy
    environment:
      CLOUDFLARE_API_TOKEN: $CF_TOKEN

# GitLab CI — $TOKEN from CI/CD variables settings
deploy:
  script:
    - CLOUDFLARE_API_TOKEN=$CF_TOKEN npx wrangler deploy
```

## Community Adoption in 2026

**GitHub Actions** is the dominant CI/CD platform for open-source projects and GitHub-hosted repositories, with the vast majority of public GitHub repos using it as their primary CI. Its tight GitHub integration (status checks on PRs, access to `GITHUB_TOKEN` for releases) and the 20,000+ community actions marketplace make it the default choice when you're already on GitHub.

**CircleCI** holds a strong position in enterprise engineering organizations that pre-date GitHub Actions (launched 2019) and built deep tooling around CircleCI's advanced parallelism and test splitting features. CircleCI's SSH debugging capability — the ability to SSH directly into a failed build container — remains unique among hosted CI services and is genuinely valuable for debugging flaky tests or build environment issues.

**GitLab CI** is the default choice for teams using GitLab as their source control platform. Its built-in security scanning (SAST, DAST, dependency scanning, secret detection) that runs without additional configuration provides security teams a complete audit trail out of the box. Organizations running self-hosted GitLab for compliance reasons get CI/CD included with no additional vendor relationship required.

## Methodology

Feature comparison based on GitHub Actions, CircleCI, and GitLab CI platforms and pricing as of March 2026, with Semaphore positioning checked against official pricing, documentation, and public GitHub repository evidence in June 2026.

*[Compare DevOps tooling and CI/CD libraries on PkgPulse →](https://www.pkgpulse.com)*

*See also: [AVA vs Jest](/compare/ava-vs-jest) and [Vercel vs Netlify vs Cloudflare Pages](/guides/vercel-vs-netlify-vs-cloudflare-pages-deployment-2026), [Chromatic vs Percy vs Applitools](/guides/chromatic-vs-percy-vs-applitools-visual-regression-2026).*