Feature Requests

Currently, notification email addresses are set at the template level, so any update to the fixed/manual email list applies to all pipelines using that template. This causes all users linked to the template to receive notifications, even when the alerts are irrelevant to their pipeline or environment. We request the ability to configure notifications at the pipeline level with conditional rules. This would allow notifications to be sent only to the users responsible for the specific pipeline or environment. For example: Prod deployments → Notify Users A and B only. PreProd deployments → Notify Users X and Y only. This enhancement would reduce irrelevant alerts, ensure the right people are informed, and improve operational efficiency.

Description: Currently, the Harness GCS artifact trigger only fires when a new file/object is added to the bucket. If an existing file is updated (new version uploaded with the same name), the trigger does not detect the change. Enhancement request: Enable the GCS artifact trigger to also listen for object updates/modifications in addition to new object creations. This would allow pipelines to run when a file is updated in place, without requiring a new filename. Impact: Current limitation prevents pipelines from running when teams overwrite or update existing files in the GCS bucket. Use case example: Customers with workflows that regenerate or patch files in place (e.g., Terraform outputs updating multiple JSON files) must rename or duplicate files to trigger pipelines, which is inefficient and error-prone.

Changes made directly in Github do not go through any validation. Harness only validates pipeline changes done through Harness UI. If we are to make a change to 300+ pipelines via Github, there is no way to run this validation right now. Request is to expose Harness validation API or build a feature where users can easily validate their feature branches.

We are using webhooks to receive notifications about pipeline events. However, there is a problem with webhooks: they can arrive out of order, or can be lost completely because of a network issue. Therefore, we need a durable audit log of all pipeline events (stored in order) that is accessible via API. Stored events should be "rich", i.e. contain all the metadata relevant to the event, such as pipeline/project tags, services and infrastructures involved (for deployment stages), as well as acting user where relevant (e.g. for approval stages).

Similar to the API: https://apidocs.harness.io/tag/Usage#operation/downloadCDUsageCSVReport , we should have API's for all modules to download license usage data in CSV

As a part of our effort to standardize processes, we want to be able to store our Custom Secrets Template Scripts as FileStore. This was shown as possible via the UI, but was later flagged as not possible, as the scripts need to be stored inline

Currently harness snow connector doc says API key is a supported authentication mechanism with service now. But I have confirmed with support that it is not a supported option. Documentation is in error. RFE: Support API Key for ServiceNow connector Pls note when using API Key the credential is passed as Header or Query parameter. Header is preferred. Pls reference ticket https://support.harness.io/hc/en-us/requests/90886?page=1 as well as slack Question https://harnesscommunity.slack.com/archives/CJZ5NCZMG/p1755114679850269

Azure Web Apps is now the standard way to deploy Single Page Apps in Azure. Would be greatly beneficial if Harness can support Azure static web apps natively. (I understand we can use Terraform to do Azure resources)

Objective: To enhance observability, monitoring, and tracing capabilities in Harness by integrating OpenTelemetry, similar to the functionality provided by CloudBees Jenkins. This integration will allow users to gain deeper insights into pipeline performance, application behavior, and system health across distributed environments. Background: OpenTelemetry is an open-source observability framework that provides standardized APIs, SDKs, and tools for collecting and exporting telemetry data (traces, metrics, and logs). It is widely adopted for monitoring distributed systems and microservices architectures. Harness, as a Continuous Delivery (CD) and Continuous Integration (CI) platform, can benefit from OpenTelemetry integration by offering users advanced observability features similar to those available in CloudBees Jenkins. CloudBees Jenkins has successfully integrated OpenTelemetry to provide users with detailed pipeline telemetry, enabling better debugging, performance optimization, and system reliability. Harness can leverage OpenTelemetry to deliver similar benefits, enhancing its value proposition for DevOps teams. Proposed Features: Telemetry Data Collection: Enable Harness pipelines to collect telemetry data (traces, metrics, and logs) using OpenTelemetry SDKs. Support instrumentation of pipeline steps, workflows, and services. Distributed Tracing: Provide end-to-end tracing for workflows and deployments across distributed environments. Visualize the flow of requests and dependencies within the pipeline. Metrics Aggregation: Collect and aggregate pipeline performance metrics (e.g., execution time, resource utilization). Export metrics to popular monitoring tools like Prometheus, Grafana, or Datadog. Log Correlation: Correlate logs with traces for easier debugging and troubleshooting. Support integration with log management platforms like Elasticsearch or Splunk. Integration with Observability Tools: Allow seamless integration with third-party observability platforms (e.g., Jaeger, Zipkin, Honeycomb). Provide configuration options for exporting telemetry data to external systems. User Interface Enhancements: Add a dedicated observability dashboard in Harness to visualize traces, metrics, and logs. Offer customizable views for pipeline telemetry data. OpenTelemetry Configuration: Provide users with configuration options to enable/disable OpenTelemetry instrumentation. Allow customization of sampling rates, data retention policies, and export destinations. Benefits: Improved Debugging: Quickly identify bottlenecks, failures, and performance issues in pipelines. Reduce Mean Time to Resolution (MTTR) for incidents. Enhanced Performance Monitoring: Gain insights into pipeline execution times, resource usage, and efficiency. Optimize workflows for better performance and reliability. Standardized Observability: Leverage OpenTelemetry’s standardized approach to telemetry data collection and export. Ensure compatibility with a wide range of observability tools and platforms. Increased Adoption: Attract users who prioritize observability and monitoring in their CI/CD workflows. Position Harness as a competitive alternative to CloudBees Jenkins. Implementation Considerations: OpenTelemetry SDK Integration: Evaluate OpenTelemetry SDKs for compatibility with Harness architecture. Instrument pipeline steps and workflows to collect telemetry data. Data Export Options: Support multiple export formats (e.g., OTLP, JSON) for telemetry data. Ensure secure transmission of telemetry data to external systems. Performance Impact: Minimize the performance overhead of telemetry data collection. Optimize sampling rates to balance data granularity and system performance. User Documentation: Provide comprehensive documentation for configuring and using OpenTelemetry in Harness. Include examples and best practices for observability setup. Next Steps: Conduct a feasibility study to assess the technical requirements for OpenTelemetry integration. Collaborate with OpenTelemetry maintainers to ensure compatibility and adherence to standards. Develop a proof-of-concept (PoC) to demonstrate OpenTelemetry capabilities in Harness. Gather user feedback to refine the integration and prioritize features. Conclusion: Integrating OpenTelemetry into Harness will significantly enhance its observability capabilities, providing users with deeper insights into pipeline performance and system behavior. This feature will position Harness as a leading CI/CD platform with advanced monitoring and tracing capabilities, similar to CloudBees Jenkins.

We need some way to tell when a pipeline was invoked directly or when it was invoked as a sub pipeline of another pipeline. This would allow us to condition some stages in the pipeline based on the source of the execution