Feature Requests

As a potential workaround to https://ideas.harness.io/feature-request/p/enable-wiz-native-scanning-w-sto-in-cd-custom-stages , which is asking for a native STO Ingest Step in the Deploy Stage, it was suggested that it might be easier to make the STO ingest Step available in the Container Step Group. This is untested, so this request is to determine feasibility and ETA if possible.

The current behaviour of GitExperience Webhooks with GitHub does not provide a very developer experience for anything other that simple scenarios. The webhook currently takes events from GitHub (pull requests), and based on the diff of the commit, it will: Create a new Harness object if there is a new file in the diff Update a Harness object if there is a modified file in the diff Delete a Harness object if there a removed file in the diff There are a number of problems with this behaviour, including but not limited to: Deletion of a file and creation of an almost similar file in the same commit shows up in the diff as an update rather than a deleted file and a new file. Deletion of a file does not fully remove the object in the Harness UI (the support ticket I raised states this is because the webhook doesn't update the Harness database). Updating the name or identifier of an existing Harness object leaves the object in a stale state where the display name and identifier show in the UI under the old name but the YAML shows the updated values (this again I assume to be a database update issue) Updating files whose 'new object' event errored for any reason (an example would be an invalid identifier when the file is first created) fails to create the object as it treated as an update to an object that doesn't exist; the solution to this involves a change to delete the file(s) then a subsequent change to re-add them back in and is a painful experience when changes require approval. Creating and then updating a second file with the same content (critically the same identifier) as an existing Harness object treats this as an update to the existing object. The expectation for the behaviour is that the webhook should treat the GitHub repository as the source of truth for all objects, and should compare the current set of tracked files with the inventory of the Harness project. It should create its own diff based on that context, and perform the appropriate action(s) to ensure that the Harness project's objects match those in the GitHub repository (errors excluded). Critically, it should also reflect changes in the database where required to keep this in line.

Values for privileged and allowPrivilegeEscalation on k8s build infra are not set unless enabled and disabled for the containerised step group. The user have to deliberately make the config changes to mark the privileged and allowPrivilegeEscalation as false. It should be taken as false if the config is not checkmarked at first.

Managing access to isolate teams to their respective namespaces in a shared k8s cluster is typically accomplished one in a couple of ways 1) Namespace specific k8s connectors, using service account token connectors -- The use of static service account tokens in k8s is common, but now considered bad practice.  This also requires customer managed automation to rotate the tokens. 2) Cloud Native connectors like an AWS connector, using a namespace isolated IAM role -- Does not work for self managed k8s cluster https://kubernetes.io/blog/2020/08/14/introducing-hierarchical-namespaces/

As a customer, I'd like to ability to kickoff a pipeline where each stage doesn’t start until you press play rather than the pipeline automatically going through every stage automatically. We are looking for the ability to kick off each stage manually. Harness Approvals do not work because they govern parallel stages. We would like for a pipeline to deploy several services in parallel but for the actual deployment to be individually controlled: svc x → dev → qa → prod svc y → dev → qa → prod In the above scenario, when the pipeline is started Harness will automatically begin deploying everything in parallel, svc x and y deploy to dev, once these stages are successful we begin to deploy to QA, etc. We'd like the option so that when you start the pipeline, nothing happens. Then you can deploy svc x to dev, then svc x to QA. After, you can decide to deploy svc y to dev. This approach adds more flexibility in what you deploy and when, though it’s manual instead of automatic.

At present, the Fail-Fast Threshold criteria can only be predefined. We would like to have the ability to configure it as a user input at runtime or expression ```yaml metricPacks: - identifier: Custom metricThresholds: - type: FailImmediately spec: action: FailImmediately spec: {} criteria: type: Absolute spec: greaterThan: 1000 # This needs to User input metricType: Custom metricName: "Response Time " groupName: DT ```

Our Vault is hosted on prem, and secure connect is needed to access it, but we don't see secure connect as an option on the connector

We are using many layers of templates and need to set up webhooks to prevent slowness. Currently there is no way to create a webhook in Harness unless the connector set on the webhook has permission to create the webhook in our GitLab instance. Our GitLab cannot connect directly to Harness, and we do not want webhooks to stack up that will be creating errors in our GitLab instance. We will be using an intermediary service to relay the webhooks from GitLab into Harness. So the ideal solution is a toggle that will allow us to create the webhook on the Harness end, but not attempt to create the webhook inside of GitLab.

Gathering data from steps to pass from stage to stage can be confusing for developers consuming templates. An ability to pass this information into a stage level output similar to how stage variables work for input would be extremely useful. An example could be a complex stage which includes build of a container image could pass the full image path and separately pass the registry, image name, tag and SHA so these are more easily passed into the deploy stage for selection of the image to deploy.

For some reason it seems like deployment type templates are not supported by the move to git operation. Support suggested we get an enhancement request open to get this supported. Technically there's ways to do this by modifying the YAML directly, but we would like this supported natively.