Feature Requests

Currently we can only add Jira Update steps within an Approval stage or a Custom stage within our pipeline. We need to update a Jira ticket whenever a status changes or whenever something is deployed. This means having to add extra stages into a CI build pipeline to update a Jira ticket with various details/status changes. Could the Jira update step be added to build & deploy stages?

When using matrix strategy for a stage within a pipeline, if one of the axes or one of the matrix execution fails, we need a way to restart just the failed matrix execution not the entire stage for every combination of matrix

When Harness creates a pull request (for example, from Git-synced pipeline or entity updates), it does not honor the repository’s GitHub pull request template (such as .github/pull_request_ template.md ). This results in PRs being created without the expected standardized description. Requested Enhancement: Automatically apply the repository’s existing GitHub PR template when Harness opens a pull request Alternatively, allow defining a configurable PR description template at the pipeline or project level within Harness Why this matters: Consistent PR templates are widely used for governance, reviews, and compliance. Supporting them would align Harness-generated PRs with native GitHub behavior and existing team workflows.

We need the ability to distinguish between Bitbucket pull request updates that contain code commits versus metadata-only changes (title edits, reviewer additions) in Harness trigger payload conditions. Is there a feature already available or can one be made?

As shown in the attached screenshot, can we add the approve message in this view instead of just saying as "waiting" in the status column. At the same time can we also add approve/reject button in the same view? This way it will allow users to quickly approve or reject multiple pipelines based on the message instead of clicking through each pipeline and then approve(or reject).

using the filter "modules": ["CI"] in the API https://transunion.harness.io/audit/api/audits/listV2?accountIdentifier is nor giving any CI specific audit events. All the CI activities whatever comes under CI module in harness should be displayed when "modules": ["CI"] " filter is used with teh above API. API doc: https://apidocs.harness.io/audit/getauditeventlist

We are currently utilizing the "Configure GitHub Action" step within a Harness CI stage to execute the actions/create-release@v1 action. This action requires several inputs, including body, commitsh, draft, prerelease, release_name, tag_name, and the environment variable GITHUB_TOKEN. We have observed successful execution of this step when using a classic Personal Access Token (PAT) with the necessary repo, user, and admin:repo_hook scopes. However, when attempting to use a short-lived GitHub App token, which is generated by a preceding plugin step, the "Configure GitHub Action plugin" step fails to create the release tag, even with the required permission_content:write granted to the token. The step consistently returns the following error: [drone-github-action/action] :exclamation: ##[error]Not Found [drone-github-action/action] :x: Failure - Main actions/create-release@v1 [430.494916ms] It is important to note that a subsequent test using a standard curl command with the exact same short-lived GitHub App token and permissions successfully created the release tag on GitHub, indicating the token itself is valid and properly authorized. Upon contacting the Harness support team, we were informed that this behavior is due to a platform-level limitation where the "Configure GitHub Action plugin" step currently does not support processing short-lived GitHub App tokens, though it works with PAT (classic) tokens. We kindly request that you consider this as a high-priority feature request to implement the necessary fix or enhancement to allow the "Configure GitHub Action plugin" step to correctly process and utilize short-lived GitHub App tokens in an upcoming release. Supporting these tokens is crucial for adhering to security best practices and leveraging GitHub's modern authentication mechanisms. Thank you for your time and consideration of this enhancement.

Provide a UI view that shows which jobs generated builds, with the ability to organize them by team and by branch. This would improve visibility and traceability, similar to how jobs are easily browsed by branch and repository in Jenkins.

Job logs should clearly display the commands being executed (for example, build and test commands) along with key environment details such as tool or DI versions. This would significantly improve debugging and reduce the need to infer behavior from indirect log output.

We'd like the ability to add multiple codebase configurations in a single pipeline. We want to run builds in parallel whille using separate codebase configurations but are running into issues where the both CI stages are using the same commitSha. Ideally codebase configurations should be set per CI stage instead of per pipeline.