Feature Requests

Allow looping strategies like matrix, repeat and parallel when invoking a child pipeline as a stage inside a parent pipeline.

As an Engineering Organization, we would like to integrate the Wiki platform with Harness to monitor metrics for some of our teams. This integration will enable us to track activities related to document creation and updates effectively. We use Atlassian Confluence as our internal Wiki platform. Your insights or suggestions on implementing this would be greatly appreciated.

Current Behavior: API /postExecuteStages: Can execute a specific stage. Requires sending the entire runtimeInputYaml payload. This defeats the purpose of InputSets, since all inputs must still be manually provided. API /postPipelineExecuteWithInputSetList: Accepts only inputSetReferences and stageIdentifiers. Always executes the entire pipeline, even if a stageIdentifier is specified. Not designed for stage-level execution. The Ask: Trigger only a specific stage in a pipeline. Reference an existing InputSet for runtime inputs. Avoid rebuilding and passing the full runtimeInputYaml. Example Goal: Instead of sending: runtimeInputYaml: | pipeline: identifier: my_pipeline stages: - stage: identifier: my_stage spec: service: identifier: my_service The customer wants to run: { "stageIdentifiers": ["my_stage"], "inputSetReferences": ["my_input_set"] } … and have the execution resolve inputs automatically from the InputSet. Impact: Current behavior creates overhead for customers with complex pipelines and existing InputSets. Inconsistent with the intended value of InputSets (avoiding re-supplying inputs). Forces additional scripting/automation outside of Harness to generate runtimeInputYaml. Proposed Enhancement: Extend /postExecuteStages to support inputSetReferences directly (along with stageIdentifiers). Allow execution of a single stage using only the InputSet, without requiring the full runtime YAML.

We manage and release all versions of our repos using a combination of semantic versioning and git tags. This means our versions are stored in tags, not branches. Can we have templates versions extended to support tags in addition to branches?

The minimum pollInterval is 2m (minutes), which is too long for certain CI/CD workflows. Creating this request to lower this poll interval timing for all artifact/manifest polling triggers

When monitoring a pipeline in the console mode (which is our preference) It would be really useful if we could expand and collapse branches after they are complete. Similar to how the stage collapses when it is done We have some quite complex pipelines with nested templates to there is a lot of steps, which is fine when they are running but when they are complete they should roll up to a step group level (if there is one) (preferably by default) And allow us to expand and collapse at each point if we need to review. Also the left hand side should scroll to match the current execution section and finally - sometimes with multiple levels we get no info on the step, having a way to increase and decrease the size of the left hand side panel would be very useful Thanks

I'd like to be able to specify only a window start or only a window end in the ServiceNow approval step so that we can hold deployments until a specific start time, but allow them to complete any time afterwards.

Currently the Account Template page does not show if a Template is referenced by any pipelines. This means to determine if a Template is in use or referenced, we have to drill into each individual template to view. Having the ability to view this at the list level, as well as the ability to filter by this, would be a massive time saver.

We'd like to manage the default settings in our projects through Terraform similar to how we are able to make these changes via the API https://apidocs.harness.io/tag/Setting#operation/updateSettingValue To give more context, we want to automate the setup of cache intelligence for our projects and be able to set the options in the S3-COMPATIBLE OBJECT STORE FOR SELF-HOSTED BUILD INFRASTRUCTURE section of the default settings.

While working in our sandbox account using the exact same Terraform configuration that we use for our primary account, we experienced some perplexing issues. As it turns out, we had forgotten to toggle a default account setting for the sandbox account. It would be incredibly helpful to have the capability to configure all resources, including account settings, using the Terraform provider. This way, we wouldn't need to concern ourselves with these matters once they are encoded in the code.