Feature Requests

https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=destroyed#merge_group

The default timeout for step execution is 10 hours. There should be an option to decrease this timeout at account/org/project level.

Description: We would like to request full support for SSH over HTTPS (Port 443) for the GitHub API within the existing connector setup. Currently, due to firewall restrictions that block Port 22 (the default port for SSH), we are unable to enable API functionality using a single connector configuration, even though the connector is set up with a valid SSH URL and the SSH key points to Port 443. Problem: While the workaround of maintaining dual connectors (one for SSH and one for HTTPS) works, it is not optimal for all use cases. The ideal solution would be to fully support SSH over HTTPS (Port 443) within a single connector configuration, making it easier to manage and more efficient in environments with strict network restrictions. Reference: GitHub provides a specific guide for this use case, which explains how to configure SSH to use Port 443 instead of the default Port 22. This is the behavior we would like to see supported within Harness. https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port (GitHub SSH Over HTTPS Guide) Request: We request that this feature be implemented, allowing customers to use SSH over Port 443 for GitHub API access without requiring multiple connector configurations.

Is there a way to freeze (prevent execution) of custom stages and CI stages as part of a freeze window? We have many pipelines which leverage these custom stages as part of deployments. Additionally, we sometimes need to freeze builds.

When a CI stage is present in a pipeline and it gets triggered by a trigger of type ARTIFACT the pipeline throws this error Invalid request: CI stage cannot be triggered by trigger of type: ARTIFACT

Trinet requires a first class support for "Git PR reversal" to undoing or reverting changes introduced by a pull request (PR) in a Git repository. This can happen for various reasons, such as if the changes introduced by the PR are found to be problematic, introduce bugs, or if they are no longer needed. Currently, we're using a script as a condition in the rollbacks. We're looking for feature to auto-rollback or revert commits that undoes the changes introduced by the PR changes essentially by using git revert command followed by the commit hash of the PR or the specific commit(s) you want to revert. ```bash git revert <commit-hash> ``` Further, the following would be a high value add to Rollback our PR processes at Trinet. ```bash git reset --hard <commit-hash> ``` ```bash git cherry-pick -m 1 <commit-hash> ``` If the changes introduced by the PR are scattered across multiple commits, you can use an interactive rebase ( git rebase -i ) to selectively remove or modify the commits associated with the PR. After reversing the changes and Rollback is executed, it's important to notify app teams about the reversal and any necessary follow-up actions to avoid any conflicts or confusion.

When defining a step's limit in the CI module, the lite-engine reflect the sum of all limits into the request. We would like to disable it or customize how much request the pod will allocate.

Can Harness add support for Dynamics 365? For reference, our end users are using this: https://marketplace.visualstudio.com/items?itemName=WaelHamze.xrm-ci-framework-build-tasks and are trying to stay with our previous CI/CD solution (ADO) because of the link provided.

1.Persistent Failure State: Issue: When accessing the tab, it defaults to not showing failures, requiring users to switch the dropdown to "All stages" to see errors. Request: Implement a persistent failure state option so that users can set their preferred view (e.g., "All stages" to show errors) as a default, reducing the need for repeated manual selection. 2.Shareable URL State: Issue: When users change the view to "All stages" and share the browser URL, the selected view is not preserved for the recipient. Request: Enhance URL sharing functionality to include the selected view state, ensuring that recipients see the same view when opening the shared link. 3.Shareable Error Details: Issue: Sharing a browser URL to specific error details (e.g., a modal dialog) doesn't maintain the context for others. Request: Enable the sharing of specific error details via URLs, ensuring that recipients are directed to the exact error and its associated modal dialog that was intended to be shared.

See https://support.harness.io/hc/requests/48562 for background. It would be a nice-to-have if all of the container pull/start events can be displayed in the console log of the Initialize step for CI/CD stages. It seems like only the first 5 step containers get displayed, then the log is truncated. We happen to have Dynatrace logging on our pods, so I can see all the events there. Related to this, it would be even nicer if there was a better connection of the container names to the step names or ids. E.g. I see step-1, step-2, etc as container names on the pod, but I can't find any reliable way to relate that to which pipeline step is running in that container, especially if the steps are parallel.