Other CI Platforms: GitLab CI and CircleCI

After this lesson, you will be able to: Recognize that GitHub Actions is one implementation of a universal idea, and read and reason about GitLab CI and CircleCI pipelines, plus build artifacts and caching that apply to all of them.

Everything you learned with GitHub Actions, triggers, jobs, steps, runners, secrets, caching, transfers directly to every other CI system. They differ in YAML dialect and a few concepts, not in fundamentals. This lesson makes you portable: able to walk into a shop that uses GitLab CI or CircleCI and read the pipeline on day one, plus the artifact and caching mechanics every platform shares.

Prerequisites:Deploy Strategies

The concepts are universal; the YAML differs

Every CI/CD platform has the same core: an event triggers a pipeline; the pipeline has stages/jobs; each job runs steps on a runner; jobs can pass artifacts and cache between them; secrets are injected from a secure store. GitHub Actions calls them workflows and jobs; GitLab calls them pipelines and stages; CircleCI calls them workflows and jobs too. Once you see that, learning a new platform is learning its YAML keys, not a new mental model. Interviews and real jobs reward the engineer who says 'I know Actions, and the concepts map straight onto GitLab CI.'

The same pipeline in three dialects

Lint + test, expressed in each platform. Notice how similar they are.

tsx

# GitHub Actions: .github/workflows/ci.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

# GitLab CI: .gitlab-ci.yml
test:
  image: node:20
  stage: test
  script:
    - npm ci
    - npm test

# CircleCI: .circleci/config.yml
version: 2.1
jobs:
  test:
    docker: [{ image: cimg/node:20.11 }]
    steps:
      - checkout
      - run: npm ci
      - run: npm test
workflows:
  build:
    jobs: [test]

Artifacts and caching (every platform has both)

Cache dependencies to speed runs; pass build outputs between jobs as artifacts.

tsx

# GitHub Actions: cache npm + pass a build to the next job
- uses: actions/setup-node@v4
  with: { node-version: 20, cache: 'npm' }   # caches ~/.npm automatically
- run: npm run build
- uses: actions/upload-artifact@v4
  with: { name: dist, path: dist/ }
# ...in a later job:
- uses: actions/download-artifact@v4
  with: { name: dist }

# Caching vs artifacts, the distinction that confuses people:
#   CACHE  = speed optimization, may be evicted, keyed by a hash (e.g. lockfile)
#   ARTIFACT = a build OUTPUT you deliberately keep / pass between jobs or download

Common mistakes only experienced engineers catch

Assuming GitHub Actions syntax is 'CI/CD' rather than one dialect of it, then freezing when a job posting says GitLab CI. Confusing cache and artifacts: caching a build output you actually need downstream (it can be evicted), or using artifacts for dependency caching (slow, wrong tool). Not keying the cache on the lockfile hash, so a stale cache hides dependency changes. Caching huge directories that take longer to restore than to rebuild. Cache the package manager's store, not node_modules wholesale, when the platform supports it. Storing artifacts forever; set retention so storage costs and clutter stay bounded.

Quick Check

You know GitHub Actions and join a team on GitLab CI. How much is transferable?

Pick the realistic answer.

←Observability and Monitoring

Back to CI/CD Pipelines

CI/CD Job Readiness→