Feature Requests

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

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

TI does not work with anything but Default Repository. The reason is that the codebase is cloned not to the root folder: /harness/ but to /harness/<somenewfolder>. The engine that initializes TI doesn't appear to be taking this into account and fails to execute git in the right folder so it fails to create a proper diff. We are getting around this by utilizing the root folder for now, but this is not ideal

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.

Need to set supplementalgroups and fsgroups and runAsGroup and others under container securityContext for gatekeeper policy compliance for the harness ci-addon ci-lite and drone images.

We would like to have the default container resources (Limit Memory – 500Mi & Limit CPU – 400m) removed so that there would be no limit set at all. Either removing it from your side works or even preferrable to give this control to us to set / remove the default limits, especially when we're relying on self-hosted build infra i.e in our case our on-prem k8s cluster. This helps us address the resource issues across the account, instead of customizing the resources specific to individual pipelines/steps which would be an overhead and also not reliable. We understand there is a FF to increase the defaults but we're not looking at that option, we're looking to have the defaults removed or the control be given to us. When we're leveraging our self-hosted build infra, we expect to have that control.

Currently there isn't any option to specify the type of image when building an image in build and push to docker registry/ECR steps. It would benefit if there is some sort of flag to be passed in Kaniko from Build and push to ECR step that would specify the image manifest type as OCI or docker v2. And depending on the input from the user, the image should be built with the respective type. Currently certain services mandate OCI images (Sagemaker for example) and the current workaround is to use skopeo to change the image type after they are pushed to ECR.

https://developer.harness.io/docs/continuous-integration/use-ci/build-and-upload-artifacts/build-and-push/build-and-push-to-docker-jfrog/#publish-build-metadata-to-a-docker-image-in-jfrog-docker-registry has been useful for our team. For the Build Metadata, we'd like the Build Metadata to include a field, for example, "Principal", that can contain the email/id/reference of who executed the build on the pipeline.

We need to remove the Test intelligence banner from the test results tab. We’re aware of the feature, but we haven’t configured it for developers yet, so they can’t enable it themselves. This causes confusion and issues for our internal support staff. Please disable the marketing banner on the test results.