Skip to content
SARC

Stage: build

The build stage turns source into the immutable container artifacts that every later stage scans, attests, and deploys. It runs right after validate and feeds security.

Part of the Full pipeline action map. Use the Fullscreen button on the diagram to view it edge-to-edge.

flowchart TD
  SRC["Source change pushed<br/>karc-portal · podtato-head · mcp-server-portal"]
  BP["build:portal<br/>buildx portal + migrator images<br/>push to GitLab Container Registry<br/>tag sha-&lt;short&gt; · capture OCI digest"]
  BD["build:podtato — matrix x6<br/>frontend · hat · left-arm<br/>right-arm · left-leg · right-leg<br/>each pushed, dual-tagged (bare + sha-)"]
  BM["build:mcp<br/>karc-mcp image<br/>(allow_failure: true)"]
  DIG["portal-digest.txt / portal.env<br/>immutable OCI digest -> fides attest"]

  SRC --> BP
  SRC --> BD
  SRC --> BM
  BP --> DIG

  class BP,BD,BM build
  class SRC,DIG io
  classDef build fill:#6639ba,stroke:#3b1f7a,color:#ffffff
  classDef io fill:#57606a,stroke:#32383f,color:#ffffff

Jobs in this stage

Section titled “Jobs in this stage”

build:portal

Section titled “build:portal”

What it does: builds two images with docker buildx in parallel — the karc-portal app and its database migrator — and pushes both to the GitLab Container Registry ($CI_REGISTRY_IMAGE/karc-portal and …/karc-portal-migrate). It tags by short commit SHA (sha-<short>) plus a context tag (mr-<iid>, main, or branch-<slug>), and captures the OCI image digest into portal-digest.txt / portal.env. Platform is linux/amd64 only (all target clusters are amd64; arm64 was dropped because QEMU emulation was 3–4× slower for no benefit).

Why: the captured digest lets the attest stage attest the exact immutable image rather than a mutable tag. The change-gate mirrors the gitops-bump rules so gitops can never point at a sha-<short> image that wasn’t built in the same pipeline.

build:podtato (matrix ×6)

Section titled “build:podtato (matrix ×6)”

What it does: builds the six podtato-head microservice images (frontend, hat, left-arm, right-arm, left-leg, right-leg) as a parallel matrix, each pushed to …/podtato-<component> and dual-tagged (bare hex + sha-<short>).

Why: the matrix isolates each component so a change to one doesn’t rebuild all six. Dual tagging avoids manifest unknown errors when gitops-bump writes image tags into the deployment manifests.

build:mcp

Section titled “build:mcp”

What it does: builds the karc-mcp server image and pushes it to the registry, tagged sha-<short> (+ context tag). On main it builds unconditionally so a fresh tag is always available; it is allow_failure: true.

Why: it mirrors the portal job’s tag shape for the downstream gitops consumers, while allow_failure: true keeps MCP build hiccups from blocking the rest of the pipeline while the integration stabilises.

Why this stage exists

Section titled “Why this stage exists”

Build-once, reference-by-digest is the foundation of the whole compliance story: the artifact that gets scanned, attested, approved, and deployed is provably the same bytes throughout. Tagging by commit SHA plus capturing the OCI digest makes every downstream attestation point at an immutable target.

Stages: validate → build → security · all stages