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!

We currently maintain two sets of charts, one for an air gap environment and the other for our public cloud deployments. The Helm Chart for airgap uses helm hooks to deploy. The Helm chart in the public cloud has lifecycle jobs that runs to facilitate the same behavior as the hooks. When I make a change to the Helm Chart for airgap, I have to write code for the Helm Chart for public cloud deployment to perform the same hook functionality.

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

Request to implement a connector for google KMS like HasiCorp Secret Manager to support cloud migration https://docs.sigstore.dev/cosign/key_management/overview/#gcp

Description Harness currently supports Pull Request Comment triggers for Bitbucket Cloud, but not for Bitbucket Server/Data Center. For Bitbucket Server/Data Center, the webhook is successfully sent to Harness and a webhook event is created, but Harness is unable to parse the PR comment event as a supported trigger type. As a result, the trigger does not evaluate and the pipeline/stage is skipped. Expected Behavior Harness should support Pull Request Comment events for Bitbucket Server/Data Center, similar to the current Bitbucket Cloud support. Use Case Customers want to trigger pipelines from PR comments in Bitbucket Server/Data Center, for example to run validation workflows only when a reviewer or developer comments a specific command on the pull request. Impact Without this support, customers using Bitbucket Server/Data Center must rely on broader PR events, move to Bitbucket Cloud, or build a custom webhook workaround.

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?

Currently, Overlay Input Sets merge multiple input sets into a single pipeline execution. We would like the option to trigger separate pipeline executions when multiple input sets are selected, allowing the same pipeline to run independently and simultaneously for each input set. This would reduce manual effort, simplify multi-environment deployments, and provide better support for parallel execution use cases while maintaining individual execution tracking and visibility.

testingtestingtesting

test ticket. please ignore

testing-testing.please-ignore