Feature Requests

We'd like for Harness to support AWS MRAP for S3 buckets. Currently Harness requires a bucket and region however, with MRAP for S3, you define one endpoint and AWS decides which bucket the data goes to.

Hello team, Please make Lite version for Harness to reduce the assets load on UI, it's very heavy especially within Enterprise network.

I would like the ability to set a retry strategy for a stage to run rerun the whole stage on failure instead of only retrying the failed step. The use case for this is we have a pipeline that goes to prod but needs a change record to be approved to move forward. The build gets to that point the moment we cut a release branch and may sit for a week or two before actually deploy. I would like to have a manual approval that times out after a period of time (12 hrs for example) that if it timed out would re-run the stage. That stage has a vulnerability check (which also happens right before the actual prod deployment). This would trigger a recheck of vulnerabilities every 12 hours. Since we could go days before we deploy to prod it is possible a new vulnerability is reported in a third party library after we get to the manual approval step but before deploy to prod which would cause the prod deployment to fail.

Hello, we are trying to use the aws-oidc-token-plugin plugin ( https://developer.harness.io/docs/continuous-integration/secure-ci/aws-oidc-token-plugin/ ) and apparently there is an input "oidcTokenId" which should have been automatically injected by Harness. But we also found out that we need to have CI_ENABLE_OUTPUT_SECRETS enabled. Is that correct? If so, please enable the CI_ENABLE_OUTPUT_SECRETS feature flag. Thanks!!

Hi Harness Team, We are onboarding iOS CI/CD pipelines on Harness Cloud macOS infrastructure using the Bitbucket connector with Connect through Harness Platform. For this setup, our Bitbucket/network security team needs to whitelist Harness Cloud / Harness Platform egress IPs so Harness can clone the repository during pipeline execution. The current allowlist requirement appears to include 100+ IP addresses / CIDR entries, which is difficult for our Infosec and Network teams to approve and maintain. Could you please confirm whether Harness can provide one of the following options for our account/region/module? A shorter CIDR range for Harness Cloud egress A smaller region-specific IP list for CI/macOS/SCM checkout only Dedicated static egress IPs for our Harness account Any supported alternative to avoid whitelisting 100+ IPs

Today there is no native Github Actions integration meaning I have to manually call the github API for kicking off builds and for logs. It would be great if there was a native plugin for those of us that don't have the CI module or want to continue using Github Actions

Enable feature flag PIPE_ENABLE_SEND_STATUS_TO_GIT, we need this to send unique pipeline status for PR builds

Currently the native jfrog step is available in the Deploy stage which supports only pushing of artefacts using the jfrog OIDC connector. We would want to pull artifacts in the build stage using the same kind of OIDC connector

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

Enable CI PR builds for Bitbucket forked repositories (external providers) Request Support CI pipeline execution for pull requests originating from Bitbucket forked repositories, even when: -The fork is owned by an external provider. -The base repository is defined as the pipeline’s codebase. Harness should correctly resolve and fetch PR refs for fork-based Bitbucket PRs and allow the pipeline to execute successfully. -Fork-based PRs trigger CI pipelines reliably. -Harness correctly resolves Bitbucket fork PR references and checks out the PR source code. -PR metadata (fork repo, source branch, commit SHA, target branch) is made available to the pipeline. -Pipeline execution does not fail due to PR ref resolution errors. -Behavior is consistent with PRs originating from the same repository.