World C2: Container Pipelines

Run tests inside containers

You will learn: to taste-test the same lunchbox your customers get.

Checked with GitHub Actions 2026-10 on 31 Oct 2026

The problem

The tests pass on the runner. Then the image crashes in production: a system library is missing. How could the belt catch that?

Watch

Tap the line where the test stage starts.

0 of 1 found

One recipe, two dishes. The test stage keeps the test tools. The app stage is what customers get. Both grow from the same base layers.

Try it

Put the belt’s steps in order.

First at the top. Put these in order. Use the arrows, or drag.

Run npm test inside that image
Build the test stage, and load it into Docker
Set up Buildx
Build the app stage and push it

Predict

One test fails inside the container. Tap the station that will stop the line, then press Run.

Which station will stop the line? Tap it, then press Run.

What happened on GitHub

Pull request

Workflow file .github/workflows/test.yml

1name: Test
2on:
3  pull_request:
4permissions:
5  contents: read
6jobs:
7  test:
8    runs-on: ubuntu-latest
9    steps:
10      - uses: docker/setup-buildx-action@v4
11      - uses: docker/build-push-action@v7
12        with:
13          target: test
14          load: true
15          tags: kedai-kancil:test
16      - run: docker run --rm kedai-kancil:test npm test

The line

Pull request · feature → main

Check

The build step says load: true. Why?

You did it!

You can now run your tests inside the image you ship.

Go deeper (optional)

Another way: put RUN npm test in the test stage. Then a failing test fails the build itself. Keep test tools out of the app stage. The shipped image stays small.

Real rep (optional), in a public practice repo:

Real mission

Add a test stage to your Dockerfile, like the one above.
Try it on your machine first.
docker build --target test -t myapp:test .
Run the tests inside it.
docker run --rm myapp:test
Add the same two steps to your workflow and push.

0 of 4 steps done · Your ticks are saved.