GitLab CI, CircleCI, and Jenkins

The plain-language idea

Everything you've learned so far — jobs, stages that gate each other, caching dependencies between runs, uploading artifacts, running on a matrix of environments — isn't a GitHub Actions idea. It's a CI/CD idea. GitHub Actions is one implementation of it. GitLab CI/CD, CircleCI, and Jenkins are three more, each with its own YAML dialect (or, for Jenkins, an actual Groovy DSL) and its own vendor-specific nouns for the same underlying concepts. Once you know the shape — trigger → checkout → install → gate checks → build → deploy — reading an unfamiliar pipeline file becomes a vocabulary problem, not a conceptual one.

This lesson is deliberately shallow: enough to read any of these three in an interview or on a new job without panicking, not a certification in any one of them.

See it in a real thing: the same pipeline, four ways

Take this repo's actual GitHub Actions job — checkout, install, typecheck, lint, test, build — and see it translated.

GitHub Actions (what this repo actually runs, .github/workflows/ci.yml):

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 24, cache: pnpm }
      - run: pnpm install --frozen-lockfile
      - run: pnpm exec tsc --noEmit
      - run: pnpm exec eslint .
      - run: pnpm build

GitLab CI/CD (.gitlab-ci.yml) — "jobs" become top-level YAML keys, and "steps" become a script: list:

stages: [verify]

verify:
  stage: verify
  image: node:24
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths: [node_modules/]
  script:
    - corepack enable && pnpm install --frozen-lockfile
    - pnpm exec tsc --noEmit
    - pnpm exec eslint .
    - pnpm build

CircleCI (.circleci/config.yml) — jobs live under jobs:, and get assembled into a run order under a separate workflows: key:

version: 2.1
jobs:
  verify:
    docker: [{ image: cimg/node:24.0 }]
    steps:
      - checkout
      - restore_cache: { key: deps-v1-{{ checksum "pnpm-lock.yaml" }} }
      - run: pnpm install --frozen-lockfile
      - save_cache:
          key: deps-v1-{{ checksum "pnpm-lock.yaml" }}
          paths: [node_modules]
      - run: pnpm exec tsc --noEmit
      - run: pnpm exec eslint .
      - run: pnpm build
workflows:
  main:
    jobs: [verify]

Jenkins (Jenkinsfile) — the odd one out: not YAML, a Groovy-based DSL, and the runner is usually a machine or container your org manages rather than a vendor-hosted one:

pipeline {
  agent { docker { image 'node:24' } }
  stages {
    stage('Install')   { steps { sh 'corepack enable && pnpm install --frozen-lockfile' } }
    stage('Typecheck') { steps { sh 'pnpm exec tsc --noEmit' } }
    stage('Lint')       { steps { sh 'pnpm exec eslint .' } }
    stage('Build')      { steps { sh 'pnpm build' } }
  }
}

The nouns shift — GitHub's "job" is GitLab's "job" too but CircleCI splits "job" from "workflow," Jenkins calls the whole thing a "pipeline" and its steps "stages." Caching is actions/cache vs. GitLab's built-in cache: key vs. CircleCI's explicit restore_cache/save_cache pair vs. whatever plugin or manual sh your Jenkins setup uses. But every single one of these files answers the same four questions: what triggers a run, what order do steps happen in, what gets cached between runs, what gets reported as pass/fail.

What people usually miss

Watch out

• GitLab CI/CD is more "batteries-included" than GitHub Actions for caching and Docker. Caching and container-based jobs are first-class top-level YAML keys in GitLab, where GitHub Actions leans on separate marketplace actions (actions/cache, docker/build-push-action) to do the same job.
• Jenkins predates the "YAML pipeline as code" convention entirely. It's older, self-hosted by default, and its Jenkinsfile is real Groovy code, not declarative config — which is also why Jenkins pipelines can do things (arbitrary imperative logic, custom shared libraries) the YAML-based systems structurally can't.
• "Which CI system is best" is the wrong question in an interview. The interviewer is almost always checking whether you understand stages, artifacts, caching, and gating as concepts that transfer — not whether you've memorized one vendor's syntax. Answer in concepts, translate to whichever tool they use.

The genealogy: this builds on pipeline anatomy

Everything here is a restatement of the pipeline-anatomy lesson's stages/jobs/artifacts model in four different vendor dialects — the concepts don't change, only the nouns and the YAML shape do.