CI that builds, gates, and publishes your image

However well you build an image and lock down how it runs (the build, the run), something still has to build it on every change and push it where the server can pull from. For a long time that something was me, on my laptop, hoping I had not skipped a check.

A CI pipeline does it on every push instead: run the checks, build the image, scan it, and publish it to a registry. A registry is the place built images live so a server can pull them; here it is GHCR, GitHub’s own. The pipeline is a GitHub Actions workflow, a YAML file in .github/workflows/ that GitHub runs for you on each push. Here is its shape.

1
name: CI
2

3
on:
4
  pull_request:
5
  push:
6
    branches: [main]
7
    tags: ['v*']
8
  schedule:
9
    - cron: '0 4 1 * *' # monthly, explained at the end
10
  workflow_dispatch:
11

12
permissions: {} # grant nothing by default
13

14
jobs:
15
  quality: # does the code pass?
16
  image: # build, scan, publish

Two jobs run in parallel. One asks whether the code is good; the other turns it into a published image. Neither trusts the input it is handed, and the second never pushes anything from a pull request.

The pipeline. A push triggers two parallel jobs. The quality job runs lint, type check, audit and tests. The image job builds the image, smoke tests it, scans it with Trivy, and on a push to the main branch pushes it to the registry. A pull request runs both jobs but skips the push.

The gate

The quality job is the gate. A red check here stops a merge instead of printing a warning nobody reads.

1
quality:
2
  runs-on: ubuntu-latest
3
  permissions:
4
    contents: read
5
  steps:
6
    - uses: actions/checkout@<sha> # v4
7
      with:
8
        persist-credentials: false
9
    - uses: actions/setup-node@<sha> # v4
10
      with:
11
        node-version: 22
12
        cache: npm
13
    - run: npm ci --ignore-scripts
14
    - run: npx svelte-kit sync
15
    - run: npx prettier --check .
16
    - run: npx eslint .
17
    - run: npm audit --omit=dev --audit-level=high
18
    - run: npm run check

npm ci --ignore-scripts installs dependencies without running their install hooks, the same supply-chain guard the image build uses. Then formatting, linting, and a type check, each one able to fail the job. npm audit --omit=dev --audit-level=high is the one people skip: it checks the production dependencies for known vulnerabilities and fails on anything rated high or worse, so a dependency with a public exploit blocks the merge.

persist-credentials: false tells the checkout not to leave a Git token sitting in the workspace after it clones, where a later step or a compromised dependency could read it.

Build once, reuse the layers

The image job builds with Buildx, Docker’s extended builder, and leans on a layer cache so it does not rebuild the world every time.

1
- uses: docker/build-push-action@<sha> # v6
2
  with:
3
    context: .
4
    load: true # keep the image local for the smoke test and scan
5
    tags: ghcr.io/you/app:ci
6
    cache-from: type=gha
7
    cache-to: type=gha,mode=max
8
    no-cache: ${{ github.event_name == 'schedule' }}

cache-from and cache-to with type=gha store the build layers in GitHub’s own cache between runs. A push that only touches application code reuses the dependency and base layers untouched and finishes in a fraction of the cold time. load: true keeps the built image on the runner so the next two steps can run it and scan it before anyone publishes it. Ignore no-cache for now; it earns its own section.

Smoke test what you ship

A build that succeeds is not a container that runs. Before publishing, the job starts the image and checks it answers, with the same flags production uses.

1
- name: Smoke test
2
  run: |
3
    docker run -d --name app \
4
      --read-only --tmpfs /tmp:size=64m,mode=1777 \
5
      --cap-drop ALL --security-opt no-new-privileges \
6
      -e API_KEY=ci-dummy ghcr.io/you/app:ci
7
    # wait for the health check, then curl /healthz and the home page

The flags are not decoration. They are the read-only filesystem and dropped privileges from the compose file. A container that passes a bare docker run can still fail under those constraints, which is its own story. Testing it any other way grades a container nobody ships.

Scan before you publish

1
- uses: aquasecurity/trivy-action@<sha> # v0.x
2
  with:
3
    image-ref: ghcr.io/you/app:ci
4
    severity: CRITICAL,HIGH
5
    ignore-unfixed: true
6
    exit-code: '1'

Trivy reads the image and lists known vulnerabilities in its OS packages and dependencies. exit-code: '1' turns a finding into a failed job, so an image with a critical hole never reaches the registry. ignore-unfixed: true skips the ones with no available patch, the ones you could not fix today even if you wanted to, so the gate fails only on things you can act on.

Publish

1
- id: meta
2
  uses: docker/metadata-action@<sha> # v5
3
  with:
4
    images: ghcr.io/you/app
5
    tags: |
6
      type=raw,value=latest,enable={{is_default_branch}}
7
      type=sha
8

9
- uses: docker/build-push-action@<sha> # v6
10
  if: github.event_name != 'pull_request'
11
  with:
12
    context: .
13
    push: true
14
    tags: ${{ steps.meta.outputs.tags }}
15
    provenance: mode=max
16
    sbom: true

The metadata step computes the tags: latest on the main branch, plus a sha- tag for the exact commit, so a deploy can pin one immutable build and roll back by changing a string. The push runs only when the event is not a pull request, which is what keeps a fork’s pull request from publishing anything. provenance and sbom attach two signed records to the image: where it was built, and a list of everything inside it. Both let whoever pulls the image check what they are running.

The monthly rebuild, and the trap inside it

A digest-pinned base image stops getting security patches the day you pin it. Two things keep it fresh. Dependabot watches the base tag and opens a pull request when a new digest appears, which the pipeline above validates like any other change. And once a month, the schedule trigger rebuilds and republishes even when nothing changed.

That scheduled rebuild has a trap, and it is the reason for the no-cache line earlier:

1
no-cache: ${{ github.event_name == 'schedule' }}

The image runs apk upgrade to pull the latest OS patches at build time. But the layer cache keys on the Dockerfile instruction, and RUN apk upgrade never changes. So the cache treats that layer as a hit and replays the patches from the last build, the old ones. A cached monthly rebuild produces a byte-identical image and a green check, while doing nothing for security. no-cache on the scheduled run forces every layer to rebuild, so apk upgrade executes instead of being replayed, and the new image carries the patches released since last month. Without that one line, the whole monthly job is a confident no-op.

Harden the pipeline itself

The workflow is software that runs with access to your registry, so it is worth the same care as the rest.

permissions: {} at the top grants each job nothing, and every job adds back only what it needs: contents: read to check out, packages: write to push. A leaked token then carries the least it can.

Every action is pinned to a commit hash, not a tag:

1
- uses: actions/checkout@<40-char-sha> # v4

A tag like @v4 moves, and an action you trust can be replaced under that tag by an attacker who takes over the repository. A commit hash is the same exact-bytes pin the base image uses, for the same reason. Dependabot bumps these too, so they do not rot.

The last rule is to never drop untrusted text, a pull request title, a branch name, into a run: line, where it would run as shell. Pass it through an environment variable instead. A pipeline that builds and publishes is a tempting place to smuggle code into.

What this costs

CI build minutes are not free, and the monthly no-cache rebuild pays full price every time by design. A cold build is slower than your laptop with a warm cache, though type=gha narrows the gap on normal pushes.

ignore-unfixed is a real trade: it means you ship images with known, unpatched vulnerabilities, because the alternative is a gate that can never go green until upstream ships a fix. You accept what you cannot act on and stay loud about the rest. And SHA-pinning every action turns into a steady trickle of Dependabot pull requests, which is the cost of not trusting a moving tag.

Your pipeline is not this pipeline

The registry is GHCR and the syntax is GitHub Actions. GitLab CI, Forgejo Actions and the rest reach the same four moves: gate, build, scan, publish, then refresh on a schedule. A project that is not a container still gates and publishes an artifact; the shape holds, the YAML does not. Read the steps as a checklist, not a file to fork.

What you end up with

Every push is linted, type-checked, audited, built, smoke-tested under production flags, scanned, and only then published, with provenance and an SBOM attached. The base image refreshes itself every month for real, not in name. Getting that freshly published image onto the server without me typing docker pull is a problem of its own.