Feature Requests

Currently when saving a template, We can add invalid field(thereisnoschemavalidationr) in yaml and it will still successfully save. Example below: template: name: BadStep identifier: BadStep versionLabel: 0.0.0 type: Step projectIdentifier: harnessorgautomation orgIdentifier: centraltech tags: {} spec: type: Run spec: thereisnoschemavalidationr: true

We’re currently working on integrating our Harness deployment process with ServiceNow Change Management and noticed that the Harness-ServiceNow integration is only available for the Vancouver release, which is now outdated. Could you kindly update the integration to support the latest ServiceNow releases?

It would be nice if we had an option for stage grouping similar to step groups. The thought is if a pipeline has selective stages enabled when i click run, I could check a group of stages to run vs having to select a ton of check boxes

We have an "init" stage in our pipeline that calculates target infras dynamically based on requirements stored in Git. The stage is set as a "deploy" type because it needs to understand the service and environment, but the infra definition variable is not used. Users are required to select an infra definition, which causes confusion since it's not actually needed. We cannot use custom stage as we can pull service-related variables in it, We want to avoid hard-coding or creating dummy infra definitions.

Description: Currently, the system only allows re-running an entire stage, a specific stage of a pipeline, or the entire pipeline. However, there is a need for more granular control to improve efficiency and reduce unnecessary executions. Use Case: When a deployment stage targets multiple infrastructures (e.g., 30 servers) and a subset of them fail (e.g., 5 servers), users currently have to re-run the entire stage or pipeline to handle these failures. This approach re-deploys to all 30 servers, which is resource-intensive and time-consuming. The requested feature would allow users to re-deploy only to the failed infrastructures (in this case, the 5 failed servers) without affecting the successful deployments. Proposed Solution: Introduce a capability within the pipeline execution process that identifies failed infrastructures during a stage execution and provides an option to: Automatically or manually select the failed infrastructures. Trigger a re-deployment only for the selected failed targets. Provide detailed logs and error reports specific to the failed infrastructures for easier troubleshooting. Benefits: Reduces time and resource consumption by avoiding redundant deployments to successful infrastructures. Improves pipeline efficiency and user experience. Enhances reliability by focusing on and resolving failures effectively.

Description: Currently, the cron expression 00 3 16-22 * 1 is intended to execute a pipeline at 03:00 AM UTC every Monday, specifically between the 16th and 22nd of a month. However, the pipeline triggers at 03:00 AM UTC on all Mondays, disregarding the specified date range (16th to 22nd). We request an enhancement to support complex cron trigger expressions that allow pipelines to be executed only when both date and day conditions are met simultaneously. This functionality would enable more precise scheduling and improve flexibility in automation. Impact: This enhancement will ensure accurate pipeline executions based on complex schedules, reducing unnecessary executions and optimising resource utilisation.

Value replacement secret injection, ie: the ability to supply a value within the ArgoApplication of something like <@dynatrace_apikey> that would autoinject a secret into the application from another secret management engine (like Vault)

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.

Hi Team Is there a way to ascertain which version of a pipeline template was used for a particular run in the execution history. at the moment the only way i can see to do this is to look in the compied yaml for changes that i know were present in the version I am after or to look at the audit trail to see what version was active at the time. it would be great to be able to easily see this in the execution history somewhere

i would like to run the stage group (build and deploy in QA) in parallel of a another stage that is "change management" like the photo attached (I can do it in Azure DevOps). as change mgmt is only needed in prod, but can be completed since the build process.