CI answer

A starter CI should run the same checks you expect reviewers to trust: install, lint, test, and build.

Make the repository contract executable

CI setup posts have strong beginner and portfolio search intent.

The four checks a starter workflow needs

CI is not decoration. It is a repeatable gate that catches mistakes before they become deployment problems.

Step Purpose
checkout Download repository
setup-node Use expected Node version
npm ci Install from lockfile
test/build Verify behavior and deployability

Build a deterministic Node job

name: CI
on: [push, pull_request]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test
      - run: npm run build

This example is intentionally small. In a real codebase, the surrounding details matter: naming, error handling, tests, runtime config, permissions, and how easy the next developer can understand the change.

Add services only when a test needs them

  • Run CI on pull requests.
  • Use the lockfile.
  • Keep jobs fast at first.
  • Cache only when it actually helps.
  • Protect main branch when the project matters.

CI shortcuts that hide failures

  • Having CI that does not run tests.
  • Using npm install instead of npm ci in CI.
  • Ignoring flaky tests.
  • Making the first workflow too complex.
  • Not matching production Node version.

Show what the green check proves

Use a concrete sentence:

I used this pattern because [problem]. The main tradeoff was [tradeoff]. I verified it by [test or check].

That structure works because it shows judgment. Anyone can name a tool. Strong developers explain why they chose it, what could go wrong, and how they checked the result.

GitHub and npm references

Keep local and CI commands aligned

A starter CI should run the same checks you expect reviewers to trust: install, lint, test, and build. Keep the implementation small, verify the edge cases, and write the decision down so the next person can trust it.

Make CI reproduce the reviewer path

A useful workflow starts from a clean checkout, installs from the committed lockfile, and runs commands that also work on a developer machine. npm ci matters because it fails when package.json and the lockfile disagree instead of silently rewriting dependency resolution.

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

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 12
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Pin the Node major version to the version the application supports. If CryptoEx is deployed with Node 22 but CI tests Node 18, a green check does not describe the deployed runtime. A matrix is useful only when the project genuinely promises multiple versions.

Keep deployment outside the first gate

Verification and deployment have different permissions and failure costs. Start with a pull-request workflow that cannot reach production. Add deployment later with protected environments, short-lived OIDC credentials, and an explicit branch or release condition. Never make every pull request capable of using long-lived cloud keys.

Also set timeouts. A hanging test should fail with enough logs to diagnose the wait; it should not consume a runner indefinitely or encourage developers to bypass CI because “it is always stuck.”

Questions before making the check required

Does the workflow run on every pull request, and does branch protection actually require it? Are the commands identical to documented local commands? Can an untrusted pull request access deployment credentials? Will a failed test keep enough logs to reproduce the problem?

Run one deliberate failure before trusting the badge. Break a test, change the lockfile incorrectly, and confirm the workflow blocks the merge for the expected reason. A green check only has value when the team knows what a red check prevents.