Feature Requests

We're trying to use the AWS Pod Identity association feature in AWS EKS, but it doesn't seem to be working. Could you please enable support for this feature?

When a Harness pipeline is triggered by a Webhook (for instance Gitlab triggered the pipeline when code is committed), the pipeline executions page -> Execution Start time column currently shows the owner of the Harness API key that is used in the Webhook. It is not very useful. Instead can you display user's email who committed the code in Gitlab?.

Currently only for pipeline entities, gitconfig is available for policy evaluation. The feature request is to make this available for all entities backed by git manifest. This will allow use cases such as "disabling direct commits to main branch" or allowing pushes only on feature or release branches.

Developers many times reject the manual approval without any reason. We want to know why developers decided no for manual approval. This information is crucial for us to know why the pipeline failed. If we know the reason, then we can try to automate and make sure there is no need for manual approval.

If there are multiple user groups and I require approval for each of them, there should some option like this. Right now I do not find any approach for this

Allowing only specific versions of services to deploy on Prod/Cob pipelines. This would help us to control deployments on production. Something that could help us mark specific versions eligible for deployment on Prod/Cob.

Issue Description: When attempting to copy or download console log output, the timestamps are not included in the copied or downloaded content. Request: Please enable the ability to copy console logs along with their timestamps. Additionally, when downloading console logs, the timestamps should be preserved and visible in the downloaded output.

Allow the Git fetch type (branch or tag) and version to be selected at runtime for manifests defined in a Kubernetes service. Problem Teams deploy lower environments from branches and production from tags. Today, the fetch type is static, making it difficult to use a single service definition across environments. Requested Capability Runtime input to choose branch or tag Ability to pass the version dynamically (for example via pipeline input) Optional fallback logic such as defaulting to tag, then branch if not found Value Enables environment-specific promotion strategies while maintaining a single reusable service definition.

Hi Team, I wanted to highlight an issue I’m seeing in our Harness pipeline. The console output logs are currently displaying in a different format than expected. If you look into the terraform CLI console outputs its different than the one I see in harness pipeline. Having the logs displayed in the correct and consistent format is important because it makes code reviews much easier and helps streamline the approval process. The current formatting makes it harder to read and trace the execution flow. Could you please look into this and help restore the expected log formatting? Please see the attached reference console output logs I am expecting in harness pipeline.

Hi Team, Client needs to replace pipeline name whichever service or job has been triggered at that time for ex: if PDB-job is trigger the pipeline name should be pdb-pipeline Thanks Sanketh