Feature Requests

The custom measures created in the Dashboard Visuzlizations cannot be added and graphed in the Visializations. Only the predefined metrics could be graphed. Could you please allow to add them as well as the predefined ones?

The option "Auto-Reject previous deployments paused in this step on approval" works only within the context of a pipeline execution where it just checks and rejects old executions waiting for approval when their latest step is approved. It does not perform checks on the environment(or any input) configured on the stage. This is currently by design. Consider a scenario where the environment is passed as an input to the pipeline when executing it. * There is an execution started with environment "Environment-1 " as the input and this was waiting for approval. * There was another pipeline that was started after the above execution and it was started with the environment "Environment-2". Once the execution with environment Environment-2 is approved, the previous execution with Environment-1 shall be rejected . It appears that when "Auto-Reject previous deployments" is enabled, the inputs passed to the execution are not compared. However, it checks to the service as long as the service is within a CD stage. The request here is to include and compare the inputs passed to a pipeline before choosing to reject the previous execution. That way pipelines only with the identical inputs are rejected when an approval is made on the latest execution.

We have plenty of developers on Windows who use Visual Studio and/or VS Code as their main IDEs. Not providing support for these IDEs would make Harness Code Assistant a non-starter when inclined to roll out a single AI coding assistant to the entire enterprise. Bonus points for XCode support, but a much lesser priority.

Currently the master url specified in kubernetes connector , if we are using the option specify master url and credential, is in plain text. This feature request is to have the ability for specifying the master url as a secret as it would be a secure approach of using the Master URL for the Kubernetes Connector.

Description: The customer is requesting the ability to use more complex node selection behavior within a step group in custom stages, similar to the functionality available in the Kubernetes Build stage. Specifically, they are looking for support for affinity rules and topology spread constraints to enable more advanced scheduling decisions. Use Case: Currently, the customer can only use a basic nodeSelector in the step group of a custom stage. They would like to extend this capability to support more complex behaviors, such as affinity rules and topology spread constraints, to improve pod scheduling in their Kubernetes environments. An example of the behavior they are looking for is the following: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "app" operator: "In" values: - RELEASE_NAME namespaces: - DEPLOYMENT_NAMESPACE topologyKey: " kubernetes.io/hostname " This configuration allows more fine-grained control over pod placement, ensuring that pods are scheduled based on their affinity to other pods, their namespaces, and their topology. The customer would like the option to apply this more complex behavior in step groups within custom stages. Desired Outcome: Extend support for advanced node selection, such as affinity and topology spread constraints, within step groups in custom stages. Allow users to define podAffinity, topologyKey, and labelSelector parameters directly within custom stages. Provide a user-friendly way to configure these advanced features, similar to the way it's done in the Kubernetes Build stage. Reason for the Request: The customer is looking to use more complex scheduling rules to ensure pods are deployed on the most suitable nodes, ensuring better resource utilization and avoiding overloading specific nodes.

Pipelines sometimes get data from external sources which have urls. In the console output of pipelines, plain urls will render as a hyperlink because that is core browser behavior since netscape. We have tried links with html, markdown, and mrkdwn (which is what Slack messages use), and these just display the raw syntax. Urls still get hyperlinked by the browser, but In the case of the html and Slack syntax, the browser incorrectly interprets some of the link text as part of the url. (See attached image) What would be ideal is for one or more of these link syntaxes be detected and converted to clickable links by the Harness' console viewer.

Currently, you can only change the Init Timeout field on a pipeline-by-pipeline basis. We would like to propose the following alternatives: * A Delegate-level setting where we can set the timeouts for every stage that uses said delegate, exposed as an environment variable. * A Project/Org/Account setting that sets the default Init Timeout value to a custom value.

Use Case: Our teams maintain independent CI pipelines separate from CD. Additionally, We have a master CI/CD pipeline using chaining. As a product requirement, they want to introduce another layer on top of this—essentially a parent pipeline that invokes the existing CI/CD chaining pipeline.

Description: NAB has requested an enhancement in Harness Services to allow the addition of key-value pairs as tags (e.g., Owner: Value, AppType: Value, etc.). Currently, while importing services into dashboards, they are unable to create separate measures where each tag is displayed as an individual column, with its corresponding values populated as column entries. Requested Feature: Provide an option to dynamically add tags as separate columns in the dashboard. Ensure that each tag's value appears as an entry under the respective column. Support multiple tags, allowing users to add and visualize multiple key-value pairs as distinct columns.

There are certain times in our pipeline where we want to stop running it and not run the rest of the steps. We can achieve this with the use of conditionals and failure strategies however, we'd like to be able to more easily mark these pipelines as success. For example, instead of aborting a pipeline and having it be shown as Aborted, we'd like a button that says Abort as success which will stop the pipeline and show it as successfully executed.