Feature Requests

I would like for failed, expired and errored pipelines to be categorized into Application vs Platform failures. Application failures would be any situation where the application team controls the solution. Platform failures are any situation where the application team has to engage another group to resolve. It would be helpful to also have a sub-category for failure. This will help us analyze failure trends for enhancements, performance, and to detect production incidents early. Examples: * Application Issues: Pipeline configuration problems, Failed tests, Expired approval, Scripting errors, Container startup failure, Policy Failure * Platform Issues: Connection Failures (e.g. artifactory, bitbucket), Delegate disconnected/restarted, Pipeline failure on any account-scope template step, POD startup failures, POD eviction

Have Favorite projects marked as enabled by default , so when a user logs back in Harness and clicks on project it by default shows him the favorites marked project, currently a user has to click on the favorites icon everytime to list the favorites marked projects. I’m having to constantly click the star icon every time which kind of defeat the purpose of favoriting projects. please, having an option to change the default behavior to sticky star selection would be nice. as a template designer, we switch b/t projects quite often.

Currently, Harness doesn't support governance policies for GitOps resources. We'd like the ability to prohibit our users from changing the targetRevision or syncing a different ref to an existing application.

I am exploring options to show some kind of a pop-up or flyer notifications to users who login to Harness tool within our enterprise. For example if we want to notify of an upcoming maintenance of the harness delegates and the downtime of it, do we have any option? I found some documentation around creating webhooks for Microsoft Teams and Slack and configuring SMTP for alerts but the functionality seems limited to pipeline alerts and would be triggered only on pipeline executions. Is there a way we can show general notifications in harness like the usecase above?

I want to be easily be able to toggle a step on/off without having to set a condition. I could potentially have a condition already set on the Step and just want to disable it without removing the condition. Another thing with the current functionality is it requires many clicks + typing in order to disable a step. This should be a simple one click + save.

Hi Team, The policies > evaluations page doesn't allow filtering by policies that resulted in a warning. It only allows filtering by Success and Failed I would like to filter based on "warning" status as well.

Today when you merge a PR, for example, that changes the pipeline configuration itself, the pipeline will trigger before the pipeline is synced with the new changes. Thus executing an old version and values for that pipeline. For this enhancement, we want that first gitX files to be synced and then the trigger will act upon them.

We have noticed a UI/UX issue within the harness platform, specifically on the configuration screen, as shown in the attached screenshot. The “Edit” and “Delete” buttons are placed very close to each other, which possesses significant risk of accidental deletions during edits.

We had some people ask if it was possible for pipelines to control the naming of stages/steps so they could see at-a-glance what the pipeline is doing instead of clicking in to the stage/step and grok the logs. For example, we have a pipeline that takes input to perform some upgrades on the provided nodes (e.g, Core,Worker,Infra). One or more of the stages may use the "repeat" strategy for each of the provide nodes and when the pipeline execution is viewed you see "Main Cluster Upgrade_0", "Main Cluster Upgrade_1", "Main Cluster Upgrade_2", etc... The order of those stages/steps will be dynamic based on the user-provided input and requires someone to click on each individual stage/step to determine what exactly the pipeline did. It would be really nice if we had some control or influence over what the labels show when the pipeline is running.

We require the ability to filter notifications on our pipelines by branch. If the pipeline is triggered from master, we want notifications to fire to the slack webhook. However, if the branch was something else, we don't want to fire notifications. This helps reduce noise and should be a simple change. We considered intercepting the webhook, which ideally we'd want to avoid, however, Harness only accepts slack domains as the webhook. Hope this simple request is clear! Please reach out to me directly if there is any further clarity required