Feature Requests

Currently, only fixed values are supported as allowed values of a runtime input. The idea is to populate a list of values in one step that could be used in the later step as the execution runtime input allowed values. Then, the end user could have the option to choose those allowed values that populated from the previous step as part of the execution runtime input.

There is no ability to redeploy without doing a CI build again when a pipeline is deployed to prod successfully. We need to have a ability to redeploy without doing CI in case of cluster repave. State needs to be persisted in order to do that. Currently its supported only when we use “re-run from last failed steps”.

Please make the emails of your recipients box in the notification section of a pipeline able to perform expression resolution. Pipeline -> notify -> new notification -> on failure -> email -> <+expression of user email based on who approved something in the pipeline> <+ pipeline.stages.Run _terraform.spec.execution.steps.HarnessApproval_1.output.approvalActivities[0]. user.email > This could be as easy as removing or changing a regex validation for the box.

Ability to map ConfigMaps (items) as a volume/files in ContainerStep This will allow to use standard container images to execute bash/python scripts using ContainerStep without building and maintaining a custom image.

Please update the ServiceNow Plugin to be compatible with ServiceNow Xanadu. Since it is not compatible, it cannot be installed with this version of ServiceNow

We would like to store pipeline.yaml in an external git in order to have a clear history of changes that are made to these configurations. By default, commits are made back to git using the service user credential defined in a git connector, but our company's engineering standards require all commits in our git instance are done by a real person, not a service user. The "Providers" functionality allows harness to commit as an individual, but there is no way to force that a user has a provider access token configured. We would like a way to enforce that pipelines cannot be saved in harness unless that save will be done using an end user's access token.

While executing the pipeline, how to hide the code/script being displayed in the execution logs.

Service was initially onboarded with INLINE as the storeType and later moved to REMOTE. However, the audit logs do not capture the change from INLINE to REMOTE.

Remove the 2-step limit from the upload files as Runtime Input feature. Several upload steps per pipeline are needed to validate individual tests. 100 MB limit is acceptable, but needs to be spread out across multiple upload steps, not just two.

Export Pipeline Metrics to DataDog Description: As a DevOps Engineer, I want to export Pipeline, Stage, and Step related metrics from Harness to DataDog in real-time so that I can monitor and track the performance of the pipelines, build success rates, and gain operational insights. Acceptance Criteria: Pipeline Metrics Export: The system must export the following metrics to DataDog: Total Build Time (start and end times) Build Time for Each Stage (start and end times for individual stages) Status of the Build (overall and per-stage status) Contextual Information Export: The exported metrics must include the following contextual data: Account> Organization> Application>Build Number>Manifest Name Metrics in DataDog Dashboard: DataDog must display the following metrics based on the data exported from Harness harness.build .time: Displays the total build time for the pipeline execution. harness.build .status: Shows the overall status of the build (success/failure). harness.build.feedback .time: Tracks the feedback time from code commit to job failure in GitHub (measured in seconds). For DataDog, The metrics end-point allows you to post time-series data that can be graphed on Datadog’s dashboards. The maximum payload size is 500 kilobytes (512000 bytes). Compressed payloads must have a decompressed size of less than 5 megabytes (5242880 bytes). If you’re submitting metrics directly to the Datadog API without using DogStatsD, expect: 64 bits for the timestamp 64 bits for the value 20 bytes for the metric names 50 bytes for the timeseries The full payload is approximately 100 bytes. https://docs.datadoghq.com/api/latest/metrics/ Real-time Data Export: -The metrics should be updated and available in real-time on the DataDog dashboard, allowing for immediate monitoring. Business Justification: -This feature is essential for enhancing the real-time monitoring and observability of pipeline performance. By exporting key metrics to DataDog, the team will gain: Improved Monitoring: Real-time visibility into build performance and potential pipeline bottlenecks. Faster Feedback Loops: Reduced time from code commit to failure detection, improving developer efficiency and reducing overall pipeline downtime. Actionable Insights: A comprehensive overview of pipeline health that supports data-driven decisions, allowing the team to troubleshoot and optimize builds effectively. By leveraging DataDog dashboards for these metrics, we enhance operational visibility, enabling the team to quickly identify and resolve issues that impact pipeline success rates and build times.