Feature Requests

United Airlines would like to request support for tag-based enforcement on Input Sets and Triggers using OPA policies. Today, OPA can evaluate pipeline-level metadata, but tags applied directly to Input Sets and Triggers are not exposed in the policy payload. Enabling this capability would allow us to enforce governance rules such as restricting which input sets can be used for certain deployments, validating trigger categorization, and ensuring consistent tagging practices across teams. This enhancement would significantly strengthen governance, compliance, and automation within our pipelines.

We had some governance demands, one of which is the mandatory use of stable versions of templates. Tried to implement an OPA Policy, however, when the template is set as stable, this information isn't displayed in the YAML. I believe it should be in some metadata. Also tried using some functions, but none of the options managed to retrieve the data from the backend. There's also no option to do this via the UI. We need a way for a OPA Policy to force the user to use only the stable version of the templates, is it possible?

Title: CI – Need a complete runtime image inventory for pre-caching (beyond get-default-config ) Problem Teams running CI on private or VM-based build infrastructure need to pre-cache container images to avoid cold pulls and keep build times predictable. Today, the GET /gateway/ci/execution-config/get-default-config?infra=K8 API only returns core CI images (lite-engine, ci-addon, some plugins), but not all images that can be pulled during real CI executions (for example security job-runners and several plugin/utility images). As a result, platform teams don’t have a single, reliable source of truth for “all images Harness may pull at runtime.” --- Pain * Build farms rely on aggressive image caching to keep build times low. * Because only a subset of images is exposed via get-default-config , teams have to: * Discover missing images reactively when pipelines pull something new. * Manually maintain a pre-cache list that easily goes out of date. * Frequent image updates or new plugin images can break the cache and reintroduce cold pulls, which: * Increases build times and variance. * Adds operational overhead just to keep the cache aligned with what Harness actually uses. --- Enhancement Request Provide a way to programmatically retrieve a complete list of runtime images used by CI and adjacent modules, suitable for pre-caching. For example: * Extend get-default-config (via a flag) or * Introduce a new endpoint that returns a “runtime image inventory” including: * Core CI engine/addon images * CI plugins (kaniko, buildx, docker/ecr/gcr/gar/acr, artifact-metadata-publisher, etc.) * Security / STO job-runner images * SSCA/SCS and other CI-adjacent images where applicable The response should include image names and tags in a structured format, so platform teams can plug it directly into their image build / cache-warmup workflows. This would let users: Pre-cache all* relevant images more reliably. * Reduce cold pulls and runtime surprises. * Spend less time chasing down “which image did this pipeline just pull?” and more time actually running builds.

Introduce the ability to add and view comments or descriptions directly within the Visual Pipeline Studio for individual Steps and Stages. Ideally, these annotations would appear via a tooltip/hover action or a dedicated "Info" icon on the UI card. Currently, there is a disconnect between the YAML editor and the Visual Studio. While engineers can add # comments in the YAML to explain complex logic or hacks, these comments are invisible to users working primarily in the Visual view. To understand the "intent" or "why" behind a specific step, a user is forced to switch context to the YAML view and search for the specific line of code.

There is no feature for propagating services in child pipeline from parent pipeline. If no, what is the alternate way we can have to propagate service and artifacts from parent pipeline to child pipeline? Let's say I have one stage(notification) in both pipeline(parent and child). We are propagating services for each stage in the pipeline. So, during runtime I want to choose service and artifact path for parent pipeline and same should apply to child pipeline.

Would like the option to automatically disable webhook triggers if the trigger failed x amount of times.

Our deployment procedure is to synchronize ApplicationSet in ArgoCD, than synchronize ApplicationSet's Applications to start a rollout of new service version. GitopsSync step in Harness does ArgoCD Applications synchronization, but do not synchronize ApplicationSets. The request is to let GitopsSync step synchronize ApplicationSet belonging to a service (in Harness), the same way ArgoCD Applications are found and synchronized by Harness Context: We are using App-of-Apps pattern in our ArgoCD setup - There is an ArgoCD Application (represents a deployment environment) that manages a set of ApplicationSets (represents applications deployed to the environment) and the ApplicationSet mages a set of Applications (every App tuns in a different k8s cluster).

Enable FF PL_ROLE_REUSABILITY_ACROSS_CHILD_SCOPES

Details I’d like to request a usability improvement for the log viewer in pipeline executions. Today, copying logs is a bit painful when you only need a specific portion of the output: * In the standard step view and console view , when logs are auto-scrolling, it’s very hard to reliably select a specific range of lines. Scrolling often deselects the text, and the selection is effectively limited to what’s currently on screen. * The “Copy” icon in the top-right of the console works, but it always copies the entire log for that step. For large logs, this is overkill when you just need a small section to share or diff. Requested improvement It would be very helpful if: * Text selection and copy worked reliably for arbitrary portions of the logs in the standard/console views, even when auto-scrolling or when the selection spans content beyond the visible viewport, and/or * There was a more ergonomic way to copy a specific range of lines (for example, “copy from line X to line Y” or similar). The main goal is to make it easier to copy only the relevant part of long logs directly from the Harness UI, without having to copy everything and clean it up in an external editor.

Allow looping strategies like matrix, repeat and parallel when invoking a child pipeline as a stage inside a parent pipeline.