Feature Requests

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 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

Subject: Conditional stage-level execution based on changed files (without JEXL) Expected behavior Users should be able to configure stage-level execution rules based on changed files in a PR or push directly in the trigger, without needing to write JEXL expressions. Concretely, for each stage in a CI pipeline, users want to: Specify one or more file path / glob patterns (e.g. services/api/ , infra/ , frontend/**) that determine if that stage should run. Use a simple, UI-driven configuration (fields similar to trigger “file path” filters) in the trigger details, instead of manually writing and maintaining JEXL against the webhook payload. Leverage the same “changed files” information already used at the trigger level, but applied at stage granularity, so that different stages can run (or be skipped) depending on which parts of the repo changed. This is a common CI pattern in other tools (e.g., “run this job only if files under X changed”), and users expect it to be straightforward to configure. Observed behavior / current limitation Today, Harness allows file path conditions at the trigger level, including “run this trigger only if certain files changed”. However, stage-level control is: Static: you can choose which stages run in the trigger configuration, but this is not dynamic per execution, or Dynamic only via JEXL, where users must: Parse the trigger payload (e.g. <+trigger.payload> / webhook body). Derive changed files manually. Write a JEXL condition per stage to decide whether it should execute. This JEXL-based approach: Is not intuitive for many users. Is error-prone and hard to maintain. Feels like an anti-pattern for what customers consider a “simple CI feature”. How to observe / example use case Customer has a PR checks pipeline with multiple stages, for example: backend-tests → should run when backend/** changes. frontend-tests → should run when frontend/** changes. infra-validation → should run when infra/** changes. A trigger is configured for PR events on a Git repo. They want each stage to automatically run only when the corresponding path patterns change in the PR. Today: Trigger-level path filters can decide whether to fire the pipeline at all, but cannot selectively run stages. Stage-level dynamic behavior requires manual JEXL against the payload to simulate “changed files” logic in the conditional execution settings. There is no built-in, discoverable UI option at the stage level to say: “Run this stage only when these files change.”

Add support for node/npm to build intelligence

Would like to achieve queue step in build stage now through CI pipelines Example: pipelineA: execution 1====>running-----stepA passed execution 2====>running-----stepA not hit yet execution 3====>running-----stepA running execution 4====>running up to stepA, then wait until all 3 running execution (1-3) completed step A, then I can start stepA As per ENG: we can have a step which always executes that does the cleanup or have a ttl associated with the key.

Provide administrators with the ability to enable or disable predefined CI steps in the Harness Step Library, so we can control on an organization or account level which steps are visible and selectable by developers. Or a way to add custom categories Use-Case 1 air-gapped environment Our organization runs Harness CI in an air‑gapped environment with no outbound internet access. Many predefined CI steps in the Harness Step Library depend on external registries, SaaS endpoints, or public container images. These steps will fail by default in our environment unless mirrors, proxies, or private equivalents are configured. Use-Case 2 custom filters/categories a way to create custom filters or categories where we can also filter down by a language or network restriction

Is there any plan to work with NPM/Github to become a trusted publisher?

We have a pipeline where we are generating some files in one stage 1 and that has to be accessed in the next stage 2 but we don't have an option for it to share files across stages. A workspace like concept is missing, if it is available then we can place the files in that is generated in one stage and access the same file in next stage.

I was wanting to see about including Golang support for intellient tests for CI stages pre build. Currently using run steps which is fine and good but thinking forward would be great to be able to also leverage IT as well. Thanks!