Feature Requests

Currently, when YAML is stored in GIT, and tags are added or updated directly in the YAML file within GIT, those changes do not update the pipeline metadata. As a result, the pipeline metadata does not reflect the new or modified tags. During execution, tags are read from the pipeline metadata — not from the YAML file — so executions do not display the updated tags. This is the expected behavior with the current bi-directional sync mechanism. However, this creates a gap between the tags defined in YAML and the metadata used during execution. Enable the pipeline metadata to be automatically updated when tags are modified in the GIT-stored YAML file, ensuring metadata and YAML remain synchronized for tags as part of bi-directional sync.

Currently, the Shell Script step does not automatically inherit or use permissions associated with a configured connector. Users must manually handle authentication, for example by writing scripts to assume roles when using OIDC. Problem Statement: This creates additional overhead and inconsistency compared to other steps that already leverage connector credentials natively. Users expect the Shell Script step to seamlessly use the same connector permissions without needing to manually replicate the authentication logic. Requested Feature: Enable the Shell Script step to optionally use connector credentials automatically (similar to how other steps handle authentication). This could be implemented via a toggle or configuration field that allows users to select an existing connector for credential context. Example Use Case: A user wants to run a script in an AWS environment using OIDC. Today, they must add logic in the script to assume the IAM role manually. With this feature, the step would automatically inherit the connector’s OIDC permissions, eliminating that extra scripting.

Currently we are working with Xcode 16.2 and Swift 6 which generates some errors with SonaQube since the version available in Harness is Xcode 16.1. There is also an instruction from Apple to update to Xcode26 for the first months of next year. https://developer.apple.com/app-store/submitting/

I need a way to prevent the platform from assigning arbitrary tasks to a delegate. It would be helpful if the platform could restrict delegate usage to specific tasks by either assigning users to it via RBAC or requiring a delegate selector to be specified. This would ensure that delegates are only used for their intended purposes and not for unrelated tasks.

Hi Team- We have a request to correlate a delegate taskId back to the pipelineExecutionId that initiated the task. Scenarios: log throw resource threshold and rejection, we want to look which pipeline execution is running these tasks on the delegate that’s potentially consuming the resources data lost prevention (dlp) block data on have taskID, we want to be able to know which pipeline execution is causing the block to be able provide context to team to resolve the issue

The pipeline studio interface should allow undo. I have accidentally hit the x button on steps while trying to click on them so many times only to lose the work I had been working on.

When setting the report on a quarterly frequency. Currently, only the last month's cost can be provided in the report. This doesn't match the frequency and period needed. UKRI would like to be able to use custom dates such as last 3 months or custom period

Right now the rollback steps can only run on certain types of non-successes (namely Failures and I believe Expiries), which leaves some potential issues unkept/unattended when pipelines are aborted or otherwise. Ideally, we want to be able to optionally perform some kinds of rollback steps on any type of status of the pipeline other than success.

PR_CHECK Pipeline webhook execution git lable change Need your availiability.

Currently, pipeline notifications lets us choose Pipeline Start/Success/Failure and Stage Start/Success/Failure. Harness also provides a "Step Failure" notification event, but no Step Start/Step Success. While notifying when specific stages start and finish covers a lot of our usecases, sometimes we want to get more granular. For example, in our production deploy stage, we perform a progressive rollout that comprises of multiple smaller deploy operations. There are also approval checks in between certain steps in the deploy stage. We want to be able to notify the user as the deploy progresses and when their approval is required. Our proposal is that Harness offer the Step Start/Step Success notification types. Because running these for every step would be undesirably noisy, these would be most useful if paired with https://ideas.harness.io/feature-request/p/pipeline-notifications-only-send-notifications-if-conditional-expression-evaluat , or another mechanism that would let us limit the notification to specific steps.