14. CI, bounded workers and safe artifacts

qatestingplaywrightindependent-practice

Saved on this device

Full lesson · 4 learning steps Open any exercise for focused practice

Step 1 of 4 · intro card

14. CI, bounded workers and safe artifacts

Concept and contract

Make the verification sequence explicit without installing a workflow into production.

CI should run the same meaningful checks in a known environment and preserve a clear failure outcome. Installing dependencies from a lockfile, type checking and executing browser tests are separate steps. A successful package installation is not evidence that any behavior was tested.

The workflow shown is an educational file inside the downloadable lab, not a new job enabled in the ApplyDjinn repository. It uses a local server and fictional data, so no production credentials or third-party feed access are required.

Mechanism and worked example

The example grants read-only repository permissions, bounds job time and runs the pinned test package.

The example grants read-only repository permissions, bounds job time and runs the pinned test package. Browser installation belongs to the CI host; local verification in this task uses the installed Chrome executable. Keep that environment difference documented when comparing results.

Worker count belongs in the test configuration. Two workers are enough for this small lab and help expose isolation mistakes without creating unbounded load. More parallelism is not automatically faster or safer on a small machine.

Complete worked example

yaml

name: QA lab
on: [pull_request]
permissions:
  contents: read
jobs:
  tests:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: "24"
      - run: npm ci
      - run: npm run typecheck
      - run: npx playwright install --with-deps chromium
      - run: npm test

Reasoning: The job preserves separate dependency, type and behavior outcomes with bounded permissions and time.

Counterexamples and common mistakes

The weak workflow ignores the test exit status with a shell fallback.

The weak workflow ignores the test exit status with a shell fallback. It can report success after a genuine failed assertion. Similarly, using continue-on-error without a clear separate decision can hide a required release check.

Avoid exposing credentials to untrusted pull-request code. The lab needs no secrets. Real authentication files and traces require a reviewed artifact policy; broad directory uploads can accidentally publish more than the intended report.

Counterexample: what this check misses

yaml

steps:
  - run: npm test || true
# A failed required test can now look successful.

Reasoning: Ignoring the test exit code can conceal a failed required check.

Independent practice: small task

Write a small workflow sequence with npm ci, typecheck and tests, read-only permissions and a finite timeout.

Write a small workflow sequence with npm ci, typecheck and tests, read-only permissions and a finite timeout. Begin with those three commands before adding an artifact step. Keep retries and workers explicit in the companion configuration.

Optional extension: retain failure traces for three days after reviewing their contents. Do not publish authentication-state files. The task is about a reviewable verification plan, not provisioning a CI service or increasing infrastructure spending.

Step 1: Write install, typecheck and test steps. Step 2: Bound permissions, workers and job duration.

Practice starter: solve before reading the solution

yaml

# TODO: locked install, separate typecheck and tests, finite timeout, no secrets.

Reasoning: Write the three verification commands before adding optional reporting.

Hint 1: Keep failures visible.
Hint 2: Artifacts may contain secrets even when tests are useful.

Solution, tests and trade-offs

The solution preserves a failing test exit code and uploads only failure evidence under a short retention policy.

The solution preserves a failing test exit code and uploads only failure evidence under a short retention policy. The verifier parses the workflow structure and runs the equivalent local commands. It does not claim that a remote GitHub Actions job was executed.

Action major versions were checked against their official releases on the review date. A real project should review and pin action revisions according to its policy. Do not silently copy an old workflow forever without checking its supported runner and runtime.

Practice solution and acceptance checks

yaml

name: QA lab
on: [pull_request]
permissions:
  contents: read
jobs:
  tests:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: "24"
      - run: npm ci
      - run: npm run typecheck
      - run: npx playwright install --with-deps chromium
      - run: npm test
      - uses: actions/upload-artifact@v7
        if: failure()
        with:
          path: test-results/
          retention-days: 3

Reasoning: The workflow is statically checked and its commands are exercised locally; no remote CI run is claimed.

Interview reasoning and next step

In interviews, trace what makes the job red and which artifact supports diagnosis.

In interviews, trace what makes the job red and which artifact supports diagnosis. Explain lockfiles, separate type checking and bounded parallelism. Distinguish a workflow definition from evidence of an actual remote run.

Next, measure latency and reliability with controlled workloads and honest limits rather than using one fast test as a capacity claim.

Optional stretch — after the core task works: Add reviewed failure traces with three-day retention.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.

Make the verification sequence explicit without installing a workflow into production.