Feature Requests

We are requesting to have the ability to mark multiple versions of a template stable to signify to our users that we have multiple stable versions. Example Versioning MajorRelease.MinorRelease MajorRelease - breaking changes - like New mandatory input MinorRelease - non-breaking changes - enhancements - optional fields 1.0 1.1 1.2 stable 1.3 2.0 2.1 2.2 Stable 3.0 3.1 Stable

Our customer requires a feature that enables Harness pipeline logs to be sent directly to third-party applications such as Grafana, Splunk, or Elasticsearch without the intermediate step of uploading logs to an S3 bucket. Key Requirements: Direct Integration: Harness should provide a mechanism to send logs in real-time to external monitoring or logging platforms via APIs, webhooks, or other supported methods. Format Compatibility: Logs should be formatted in a manner compatible with popular log management systems, such as JSON or plain text. Customizable Endpoints: The feature should allow customers to configure custom endpoints for log forwarding. Security: Support for secure log transmission protocols (e.g., HTTPS) with authentication options (e.g., API keys or OAuth). Filter and Selection: Customers should have the option to filter logs or select specific steps/stages of the pipeline for forwarding. Benefits: Eliminates dependency on S3 buckets for log storage. Provides real-time visibility into pipeline execution logs within existing monitoring or analytics tools. Reduces latency in log access and analysis. This feature will improve the flexibility and usability of Harness for customers who rely on external tools for log management and monitoring.

In “always pull latest” for templates, the dropdown shows "Select" as default, which is confusing for users, as this makes them think they need to select a version even though they are actually pulling stable automatically. Instead of seeing “Select” users should see the stable version.

Currently in IACM Approval stage, only 1 approval is required to run terraform apply. Therefore in our current setup, we had to introduce another Manual Approval stage before terraform apply so that pipeline will continue only after 2 approvals for higher environments. So, we need a feature in IACM Approval stage to allow multiple approvals before terraform apply.

I have a pipeline that I plan to only execute manually, but would like to implement selective stage execution depending on which inputset is run, without relying on triggers

Our team hits the Github Rate Limit at times, and investigating these issues is time consuming. We would like Harness to please return data from the rate limit error header so that we can see 1) What account is causing the rate limit 2) What is the limit count at the time https://docs.docker.com/docker-hub/download-rate-limit/#how-can-i-check-my-current-rate For example, this information is not provided in DiND ERROR MESSAGE: GET https://index.docker.io/v2/library/docker/manifests/dind : TOOMANYREQUESTS: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

Widget to track status of epics and analyze work done, pending, distribution and estimation.

Even after enabling FF CDS_LIST_REPO_V2, GitX pipelines are not displaying results when searching for GitHub Branches. GitHub’s REST API does not support searching for branches, but this can be achieved through one of the following avenues: 1) Using the REST API "Search References" endpoint (GET /repos/{owner}/{repo}/git/matching-refs/heads/), where this endpoint can be used to filter/search any matching references, including branches: https://docs.github.com/en/rest/git/refs?apiVersion=2022-11-28#list-matching-references 2) Use GitHub’s GraphQL API (instead of REST API), which does have a branch search endpoint: https://docs.github.com/en/rest/about-the-rest-api/comparing-githubs-rest-api-and-graphql-api?apiVersion=2022-11-28

With the recent Semantic Search feature update to the existing Code Search functionality of Harness Code Repository, please add a note in the documentation that we need to enable a certain feature flag to use the new feature.

When deploying to ECS, the deployment failed (see events below) but Harness does not detect the failure and reports the deployment as successful. We now need to add our own post-deployment checks to fail the deployment and rollback the stage, something that Harness should be doing automatically. Include task status for ECS Rolling Deployment