Feature Requests

Right now harness only allows to run shell script only at run time. is it possible enabling python script also to run at runtime.

Right now Harness allows only shell script to run on runtime. is it possible to add python script also to run at runtime in similar way like shell script? Please find attached screen shot

provide support to restore cache dependency automatically using npm install for node without using custom path Currently It is supporting for yarn install with default path (.yarn) So If you can also provide support for npm install with default path(node_modules) then It will be really helpful for us.

We'd like the ability to run the local runner as a service instead of just executing it directly while in the machine. This is to help improve uptime in case the runner goes down for any reason so we don't have to manually SSH into the machine and reboot the runner every time.

plugins/cache plugins/sto plugins/s3

Currently, Harness provides a single Docker plugin that can be configured for: Build and Push Build Only Push Only This is controlled through environment variables. However, when integrating a container scanning step (e.g., Prisma), the workflow becomes cumbersome because we need to: Use one Docker plugin for Build Only Use a separate Docker plugin for Push Only Add a third plugin for Scan This results in multiple steps and plugins, making the pipeline less intuitive and harder to manage visually. Feature Request: Introduce a unified Docker plugin that supports: Build Scan Push …all within a single plugin configuration via the Harness UI (Visual View). This would allow users to: Configure scanning tools (like Prisma) directly within the same plugin. Reduce pipeline complexity and improve maintainability. Provide a more streamlined experience for container lifecycle management. Why This Matters: Simplifies pipeline design. Reduces the number of plugins and steps required. Improves usability for teams adopting container security best practices.

Context : Following the investigation in Support Ticket #98593, we identified that the Test Intelligence (TI) agent (both v1 and v2) fails to execute in hardened container. Current Limitations: The TI agent currently operates on implicit assumptions about the underlying Python environment that cause failures in secure images: - Root Assumption: The agent attempts to install dependencies (e.g., pip install coverage) assuming it has write access to system-level site-packages. This fails in containers running as a non-root user (e.g., USER 1001). - Path Assumption: The agent fails to discover coverage reports or dependencies (specifically pytest-cov) if they are installed in custom locations (defined via PYTHONPATH), even if those locations are valid and accessible to the shell. Desired Behavior / Request: Environment Agnostic: The TI Agent should respect the existing environment variables (like PYTHONPATH and PATH) and run successfully as a non-root user. Configurable Paths: If auto-discovery is not possible, provide explicit plugin configuration options to point the agent to the correct coverage or dependency folders. Documentation: If strict environmental prerequisites (like root access) are unavoidable, they must be explicitly documented in the official setup guide. Steps to Reproduce (from Ticket #98593): 1) Use a Python base image configured with a non-root user. 2) Install pytest and coverage in a user-local directory (e.g., /home/app/.local). 3) Configure a "Run Tests" step with TI enabled. Result : The step fails with ModuleNotFoundError or report discovery errors, despite the tests running successfully in a standard shell step.

The possibility to add --disable-rollback to Create Cloud Formation Stack Step, example with aws cli: aws cloudformation create-stack --stack-name myteststack --template-body file://mytesttemplate.json --disable-rollback

We have a use case where custom stage is used to pull the precompiled artifact from artifactory , we want to publish artifact metadata in 'artifacts' tab during custom stage execution This feature request is to enable custom stage to support 'artifacts' tab in harness saas.

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