Problem In Harness CI, each step creates its own ephemeral container even when multiple steps use the same image. This increases build time, image pull overhead, pod/container churn, and Kubernetes load. Many pipelines naturally group related steps (e.g., build + test in the same toolchain), but Harness cannot currently express “reuse this container across steps”. This differs from established patterns in Jenkins, Tekton, and other K8s-based CI systems. ⸻ Proposal (Opt-In) Introduce an optional stage-level feature that allows users to: 1. Define named containers in the stage (e.g., build, node, tools). 2. Assign steps to those containers via a simple container: <name> field. 3. Harness initialises each named container once per pod, and runs all referencing steps inside it sequentially. 4. Default behaviour (one container per step) remains unchanged for users who want strict isolation. ⸻ Value • Performance: avoids repeated container startup and image checks; reduces CI latency. • Efficiency: lowers registry traffic and node/kubelet workload; improves cluster utilisation. • Better modelling: aligns with how teams naturally structure pipelines and with patterns from other CI systems. • Safe & incremental: fully optional; no breaking changes; ideal for advanced users who want faster pipelines. ⸻ Example YAML the spec section could be updated to hold the pod spec before the steps. Something like stage: name: Full SDLC Validation type: CI spec: Opt-in: define shared, named containers once per stage pod: containers: Build & test toolchain - name: build image: maven:3.9-eclipse-temurin-21 could mount a cache volume here in future Image build toolchain (e.g. Kaniko / BuildKit / Docker CLI wrapper) - name: image-builder image: gcr.io/kaniko-project/executor:latest Security tools (SCA, image scan, SBOM) - name: security image: aquasec/trivy:latest steps: 1) Compile + unit test (classic inner-loop) - name: compile-and-unit-tests container: build command: mvn -B clean verify 2) Static analysis / linting using Maven plugins - name: static-analysis container: build command: mvn -B spotbugs:check checkstyle:check 3) Package JAR / artefacts (if not already from previous goal) - name: package-artifacts container: build command: mvn -B package 4) Build container image from Dockerfile using dedicated image builder - name: build-container-image container: image-builder command: > /kaniko/executor --dockerfile=Dockerfile --context=. --destination=registry.example.com/my-team/my-service:${HARNESS_BUILD_ID} 5) Image security scan & SBOM generation - name: security-scan-and-sbom container: security command: > trivy image --scanners vuln,secret,config --format sarif --output trivy-report.sarif registry.example.com/my-team/my-service:${HARNESS_BUILD_ID} 6) Contract/integration tests against the built image or a test deployment - name: contract-tests container: build command: mvn -B -Pintegration-test verify
