Feature Requests

Ability to have pipeline expressions for Unit Test and Vulnerability data, not output variables from steps. We have pipeline templates, custom pipelines and this would make it easier to pull test, security data from a generic place instead of having to rely on specific steps output variables which can be cumbersome and also leaves room for this information to be spoofed. if we could pull the information from the /Tests and /Vulnerabilities endpoints it would be helpful!

Add support for self-hosted GitHub Enterprise to connect from Harness for security purpose and short lived tokens

What works elsewhere: Local Docker Compose: additional_ contexts.aws : ~/.aws works as expected. GitHub Actions: docker/build-push-action@v6 with build-contexts: aws=backend/python/docker/ci-aws works as expected. What fails on Harness Cloud: Failure mode 1 — caching: false (plain docker build) With caching: false, build logs show plain docker build (no buildx, no --build-context). BuildKit then resolves from=aws as a Docker Hub image: #6 [internal] load metadata for docker.io/library/aws:latest #6 ERROR: pull access denied, repository does not exist or may require authorization Base image stages without from=aws succeed; service image stages that use the named context fail. Failure mode 2 — caching: true + PLUGIN_BUILDX_OPTIONS Per your docs, caching: true enables buildx, and named contexts should be passed via PLUGIN_BUILDX_OPTIONS. We configured: caching: true envVariables: PLUGIN_BUILDX_OPTIONS: "--build-context aws=/harness/backend/python/docker/ci-aws" Build fails immediately with: unknown flag: --build-context aws Usage: docker buildx build [OPTIONS] PATH | URL | - It appears Harness splits PLUGIN_BUILDX_OPTIONS on =, so --build-context aws=/harness/... becomes an invalid flag --build-context aws (path dropped). A prepare step runs before the build and writes credentials to /harness/backend/python/docker/ci-aws/ (verified present on the VM). Failure mode 3 — buildAdditionalContext YAML field We also tried (not in your published BuildAndPushECR docs): caching: true buildAdditionalContext: aws: backend/python/docker/ci-aws Same docker.io/library/aws:latest error as failure mode 1 — suggests the field is ignored or not wired to the drone-docker/buildx plugin on Harness Cloud. Questions for Harness: What is the supported, documented way to pass Docker BuildKit named build contexts (--build-context name=path) from a BuildAndPushECR step on Harness Cloud? Is buildAdditionalContext a valid field for BuildAndPushECR? If yes, what is the correct schema, and which build infrastructures/plugin versions support it? Is the PLUGIN_BUILDX_OPTIONS = splitting behavior a known bug? Is there a workaround (e.g. PLUGIN_BUILDX_OPTIONS_SEMICOLON, stage variables, or another env var) to pass --build-context aws=/harness/... intact? Does PLUGIN_BUILDX_OPTIONS_SEMICOLON work on Harness Cloud for this use case, or is it only for comma-containing values like --output=type=tar,dest=...? Are named build contexts supported only on Kubernetes build infra (e.g. with CI_USE_BUILDX_ON_K8), and not on Harness Cloud?

I have a test pipeline in which ,one step creates 3 txt files : /harness/dir1/dir2/a.txt /harness/dir1/dir2/b.txt /harness/dir1/dir2/c.txt i would like to upload these files to s3 bucket using the s3 plugin, to the destination s3:////a.txt ..etc however i am not able to place these files in the above path. harness always creates a directory structure of the source file in the s3 target.

Summary Harness currently lacks a native mechanism to generate ephemeral, short-lived API tokens at pipeline runtime — comparable to GitHub Actions' GITHUB_TOKEN or the OIDC-based tokens available for GCP and Azure in Harness CI. Reviewed Documentation & Why It Is Insufficient API Keys & Token Expiry https://developer.harness.io/docs/platform/automation/api/add-and-manage-api-keys https://developer.harness.io/docs/platform/automation/api/add-and-manage-api-keys#token-expiry Harness allows setting an expiration date (30, 90, 180 days or custom) when creating a token. However, this is a statically configured expiry, not a dynamically generated short-lived token. The minimum API key duration is 30 days. This does not meet the requirement for tokens that are valid only for the duration of a single pipeline run. Delegate Token Revocation Delegate tokens can be created with a revokeAfter epoch timestamp via API. However, this mechanism is scoped to delegate authentication only and is not applicable to general CI pipeline use cases. IDP Create/Delete Secret Pattern https://developer.harness.io/docs/internal-developer-portal/tutorials/using-secret-as-an-input/ The IDP workflow pattern allows creating a Harness secret before a pipeline run and deleting it afterward using harness:create-secret and harness:delete-secret actions. This is a workaround, not a native solution — and explicitly noted in the documentation that if a pipeline step fails, the secret is not automatically cleaned up, requiring manual deletion. Token Rotation [Rotate tokens] Token rotation is a manual process and does not provide runtime-scoped ephemeral tokens. What Is Needed A native Harness CI mechanism to generate a short-lived, pipeline-scoped token at runtime that: Is automatically invalidated when the pipeline run ends. Requires no manual cleanup. Can be used to authenticate against the Harness API within the same pipeline run. Is comparable to GitHub Actions' GITHUB_TOKEN or the existing OIDC plugins for GCP https://developer.harness.io/docs/continuous-integration/secure-ci/gcp-oidc-token-plugin/ and Azure https://developer.harness.io/docs/continuous-integration/secure-ci/azure-oidc-token-plugin/

Our security team has requested that it be recorded in an audit log when a secret is exposed via an export and is visible on the output tab.

I need create trigger for pipeline trigger run, I do not have access currently, kindly provide access to create trigger for my pipelines executions

We were going through this feature to visualize CPU and memory utilization metrics on Cloud builds: https://developer.harness.io/docs/continuous-integration/use-ci/set-up-build-infrastructure/view-resource-utilization-metrics/ Is there a plan to provide the same feature on self-managed build infrastructures? Any ETA for this feature?

We have a CI pipeline triggered by GitHub Pull Request webhook events that runs functional tests for 14 connectors. We need <+trigger.changedFiles> to be populated at pipeline runtime to conditionally run GitClone steps and functional tests only for connectors whose source files were changed in the PR. Currently, <+trigger.changedFiles> resolves to null at pipeline execution time for PR-based triggers, even though the trigger fires correctly and changedFiles works as a gate condition. Support confirmed this expression is only supported for push-based triggers under the PIPE_TRIGGER_CHANGED_FILES_EXPRESSION flag. We'd like this expression to be extended to PR-based webhook triggers as well, consistent with how it already works for push events. Without this, we're forced to either run the full test suite on every PR across all 14 connectors (wasteful and slow), or maintain a fragile custom script workaround. PR-based triggers are a very common CI pattern, and native support for <+trigger.changedFiles> in this context would benefit a wide range of Harness users.