Feature Request: Allow Steps to Reuse a Shared Named Container Within a CI Stage (Opt-In)
long-term
S
Senior Turtle
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
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
6) Contract/integration tests against the built image or a test deployment
- name: contract-tests
container: build
command: mvn -B -Pintegration-test verify
Log In
s
shivkumar.loka
marked this post as
long-term