Feature Requests

Description: Sysdig is requesting a feature that provides a structured dashboard to track and compare service versions across multiple environments. This functionality was previously available in Harness FG and was very useful for quickly identifying version mismatches and ensuring consistency between environments. This will help teams: Identify version mismatches between environments Track deployments efficiently Ensure services remain in sync across different stages

The Harness API is very difficult to use because of all the inconsistencies. To name a few: no standards in how api calls are done. no consistent CRUD calls for the resources. URLs are all over the place. paging is done at least three different ways documentation is very sparse and missing key details, example: what is the syntax of the sortOrder query parameter? documentation shows many "beta" apis, with no indication of whether they should or could be used. I’ve encountered three different ways to do paging for APIs that return lots of entities: Use query params size and page, return in response headers to return paging information, example: https://apidocs.harness.io/tag/Project-Roles#operation/list-roles-project Use query params size and page, return in body , totalElements, totalPages, size, number example https://apidocs.harness.io/tag/Pipeline-Execution-Details/#operation/getListOfExecutions Use query params pageSize and pageIndex, return in body , totalPages, totalItems, pageItemCount, pageSize example: https://apidocs.harness.io/tag/Project-Roles#operation/list-roles-project The REST API standards could come in very handy and make the API more useable.

Summary: When configuring pipeline variables to accept YAML or other lengthy input, the current single-line input box is impractical and cluttered. Providing a multi-line text area—or an expanded code-like editor—on the “Run Pipeline” window would improve usability and reduce input mistakes. Problem Statement / Pain Point: Large YAML or JSON content is difficult to edit and review in a cramped single-line field. Users are more prone to syntax errors or formatting mistakes due to limited space. The current flow diminishes productivity by forcing repeated scrolling or external text editors. Proposed Solution: Replace the single-line input with a multi-line text area that automatically expands, or add a toggle to switch to a code editor view. Offer basic formatting or syntax-highlighting to ease reading and editing. Benefits / Impact: Improves user experience by making it simpler and quicker to provide or adjust complex inputs. Decreases errors and rework caused by formatting issues. Streamlines the pipeline setup process for teams working with large YAML configurations.

Enhance Harness pipeline governance by enforcing environment progression rules (DEV → QA → STAGE → PROD) while enabling traceability of previous deployments through Change Management tools like ServiceNow. Problem Statement: Currently, Harness pipelines allow deploying to any environment based on input parameters (SERVICE, ENVIRONMENT, INFRA, GITCOMMIT). However, there is no built-in mechanism to: * Enforce that a service has successfully deployed to DEV before QA, QA before STAGE, and STAGE before PROD when pipelines are triggered days apart. * Maintain traceability of previous environment deployments and associate them with pipeline stages/steps for external Change Management systems like ServiceNow. Proposed Solution: Deployment History Validation: * Introduce a precondition step or built-in policy to verify if a service has been successfully deployed to the required previous environment before proceeding. * Example: If deploying to QA, the pipeline should check if the same GITCOMMIT has been successfully deployed to DEV first. * Harness should store and validate deployment history (could integrate with existing audit logs or metadata storage). Deployment Traceability & External Integration * Add metadata linking pipeline execution IDs, stages, steps, and their respective environments. * Provide APIs or webhook triggers to update Change Management tools (e.g., ServiceNow) with deployment data. * Example: A ServiceNow record can contain the pipeline execution from DEV before approving QA deployment. Time-Gap Resilience * Since pipelines are executed at different times (days apart), Harness should persist deployment state beyond a single pipeline run. * Could be stored as pipeline metadata or through an external database integration. Expected Outcome: * Governed pipeline flow ensuring controlled environment progression. * Improved traceability of service deployments across environments. * Seamless integration with Change Management tools for compliance and approvals.

Currently, our deployment logs for certain steps are larger then 2mb causing the drone job to not be marked as 'completed' when the step itself has. Therefore the drone pipeline for this job, remains in a continuos running state and never ends. We can implement various work around, but it would be beneficial to have log size limits to not be hard coded and be soft coded environmental value we can set.

If you have a Harness Expression in a Shell Script that's been commented out, Harness will still try and evaluate it which can cause unexpected failures. We'd like for the comments to not evaluate any expressions.

Description: Nationwide Building Society has requested the ability to change the secret manager connector reference for existing secrets within Harness. Currently, Harness does not allow updating the connector (i.e., the secret manager reference) once a secret is created. In their setup, they are using Vault as the secret manager and have two connectors configured to point to the same Vault instance — ConnectorA and ConnectorB. All existing secrets were initially created using ConnectorA. They now want the flexibility to update those secrets to reference ConnectorB instead, without recreating the secrets. Use Case: Organizations often configure multiple connectors pointing to the same backend secret manager for reasons such as scoping, access control, or organizational structure. Over time, there might be a need to switch the connector used by existing secrets — either due to connector deprecation, policy changes, or infrastructure updates. Currently, this is not supported in the UI or via YAML, and users are forced to manually recreate secrets.

Please add support for OPA v1.X. See the reference here: https://www.openpolicyagent.org/docs/latest/v0-upgrade/#general-upgrade-approach-upgrade-producers-then-consumers Additionally in your policy documentation, could you please add the current syntax version that is supported?

We are looking for support so that we can track our Openshift deployments. When looking for methods to do so either with manifest types, or with Infrastructure tags, we found that Harness does not provide these fields for their Dashboards. We have no way to retroactively look at our deployments

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.