Feature Requests

Many reports such as coverage, linters, unit tests from various languages, etc use proprietary HTML reports. Harness enables you to upload these reports as artifacts to S3 or similar, but it does not support HTML reports natively. I would like to see this feature make it to Harness similar to https://plugins.jenkins.io/htmlpublisher/ to support additional quality and build reports

Currently the step logs are getting truncated when it is exceeding a size of 5MB. The workaround suggested to save the script output to a file and make it available in an object store is not helpful and having issues using this workaround in the run test step. We should be able to see the full step logs even if it is exceeding the sizes of 5MB

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

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.

The node pool is to be set to linux by selecting linux node in the cluster. But our question is we have given the "Select the Operating System" as "Linux" under Infrastructure -> Platform section. However, the node selector remains blank and has to be entered manually. We want to have the option to auto-populate the node selector when the node pool is entered. we have more than 100+ templates, it's causing to much work for us to update the existing template.

Developer experience would be improved if there was a simple way for environmental variables to persist across steps in a stage. Right now we frequently have to set the same variables for each step which are outputs from a first step. This is very repetitive and can be prone to mistakes if you start involving expressions. as a specific example, we assume a AWS role and have to add the AWS environmental credential variables to each subsequent step that uses it. this is inconvenient and repetitive when setting up pipelines. It's also not fun to have to deal with those output expressions. Some more user-friendly way to persist these or set once would improve dev experience. especially if it can be set from within a template so that it's just plug and play

E.g. in this yaml: step: type: Run spec: connectorRef: My_Artifactory_Docker image: <+ variable.my _step_runner> For CI run steps in self managed Kubernetes, it would increase flexibility and reduce maintenance if 'connectorRef' and 'image' could be combined to a small Harness template with versioning capability. That way, we could keep a Stable version for most steps and pipelines, but create and easily test a new template version with an experimental step runner image. For example when we need to add a new dependency or base OS upgrade for our generic image, we could safely validate on one step or pipeline, then move the stable version forward and quickly update all pipelines.

Currently, our CI pipeline outputs unit test results to a file, and in a subsequent stage of the pipeline, we upload that result to an existing ServiceNow Change Request (manually, using the Attachment API). In order to access that file across stages, we're currently dependent on an S3 Cache. I know test results are being stored across stages, because we can view them in the Tests tab, but it would be great to be able to access those values as a file in the file system, or with a built-in variable.

Currently, you can only change the Init Timeout field on a pipeline-by-pipeline basis. We would like to propose the following alternatives: * A Delegate-level setting where we can set the timeouts for every stage that uses said delegate, exposed as an environment variable. * A Project/Org/Account setting that sets the default Init Timeout value to a custom value.

Allow barriers to be used in build stages. Use case is we want to build multiple parts of an application in parallel and use a barrier to wait for all builds to finish before we then publish them. We don't want to publish as soon as built because a subsequent deployment pipeline is triggered on new artefact. The pipeline needs all the parts to work properly.