Feature Requests

Currently, when Harness CI stages are marked as required checks in GitHub PRs, any stage that is not triggered due to conditional execution or trigger filters does not report a status, causing the PR to remain indefinitely blocked. GitHub supports a “skipped” status for checks, which is treated as a success and does not block merges. We request that Harness report a “skipped” status to GitHub for any CI stage that is intentionally not executed, enabling users to leverage conditional pipeline logic without impacting PR mergeability.

During Pipeline configuration/execution with Infrastructure Configured over K8s Cluster Advanced options allow us to configure the Pipeline Pod's securityContext using following block: containerSecurityContext: capabilities: drop: - ALL privileged: false allowPrivilegeEscalation: false runAsNonRoot: true runAsUser: "1000" In case the checkbox to enable these settings is are left unchecked/unset, we still want the following to be configured for the pipeline spec explicitly. capabilities: drop: - ALL privileged: false allowPrivilegeEscalation: false runAsNonRoot: true runAsUser: "1000"

What: Ability to retry/re-trigger a failed Harness pipeline directly from GitLab without navigating to the Harness UI. Current State: Not supported natively. Must go to Harness UI, use API, or re-push commit. Workaround available (CI only): Configure a MR Comment trigger — developer posts a specific comment (e.g., /retry) on the MR, which triggers a new pipeline execution. Works for CI stages only, not CD.

If the Terraform plan fails, the pull request is not marked as a build failure. This introduces a potential risk, as an approver may inadvertently approve the PR, allowing invalid infrastructure code to be merged into the develop branch.

Hi Team, Good Day! At the template level, the multi-service selection option is available under the Deployment stage, however, when we attempt to configure this at the pipeline level or input set level, the UI and YAML do not allow selecting multiple ECS services — only a single serviceRef can be provided under spec.service, with no option to switch to spec.services (multi-service) from the input set. Please provide guidance on the supported approach to achieve multi-ECS-service deployment. https://app.harness.io/ng/account/iT5C2SaoSbi_31HYqXYfTA/all/orgs/ACITCustomerDigitalTeam/projects/ACITCCT/pipelines/featureecsdeploytest/pipeline-studio/?storeType=REMOTE&connectorRef=account.acdevopsgithubharnessconnectorssh&repoName=ac-it-customer-digital-harness-templates&branch=main Thanks, Amanulla

PayPal is executing a large-scale CI/CD platform consolidation, migrating all engineering teams — to Harness before a hard deprecation deadline Several of these BUs have existing pipelines authored in GitHub Actions (GHA). There is currently no native, low-friction path to migrate GHA workflows to Harness pipelines. We are requesting Harness invest in a GitHub Actions → Harness migration utility to reduce migration effort and accelerate adoption. Problem Statement Teams migrating from GitHub Actions to Harness today face a fully manual effort: GHA workflow YAML (.github/workflows/*.yml) has no automated translation to Harness pipeline YAML Developers must re-learn step syntax, trigger definitions, secrets references, environment variable handling, and artifact management from scratch There is no tooling to inventory GHA workflows across repos and generate migration estimates High migration friction directly threatens delivery timelines and increases DPE support burden Requested Capability We are requesting Harness build and ship a GitHub Actions → Harness Migration Utility with the following capabilities: GHA Workflow Parser & Analyzer Scan a GitHub org or repo and inventory all .github/workflows/*.yml files. Output a migration complexity report classifying each workflow as Simple / Medium / Complex based on step count, custom actions used, matrix strategies, reusable workflows, and secrets usage. Automated YAML Translator Convert GHA workflow YAML to equivalent Harness pipeline YAML with best-effort mapping of: on: triggers → Harness trigger definitions (push, PR, schedule, workflow_dispatch) jobs: → Harness stages steps: → Harness steps (Run, Plugin, or Build & Push steps) env: and secrets.* → Harness variable and secret references uses: (GitHub Actions marketplace) → equivalent Harness plugins or delegate steps, with an unmapped actions report for gaps Migration Confidence Scoring Each translated pipeline receives a confidence score (High / Medium / Low) indicating how much manual review is needed post-translation. Low-confidence items should surface specific callouts for the developer. CLI + UI Integration Expose the migration tool both as a CLI (harness migrate github-actions) for scripted bulk migrations and within the Harness platform UI for individual pipeline migrations — consistent with the existing Jenkins migration path. Migration Audit Trail Track which GHA workflows have been migrated, by whom, and to which Harness pipeline — surfaced in the Harness platform for program-level visibility. Business Justification Teams with GHA-based pipelines represent a long tail of migration work with limited support bandwidth. A native migration utility would: Reduce per-pipeline migration time from days to hours for common patterns Enable Teams to self-serve migration without requiring deops to build pipelines on their behalf Accelerate Harness seat utilization and license realization

Enable Harness Remote CI Debugging feature flag CI_REMOTE_DEBUG

When Test Intelligence is enabled, some tests are skipped, and the generated report includes only the tests that were executed. This leads to a significant drop in coverage when integrated with SonarQube. Since Harness already has visibility into the skipped tests, we are looking for a way to have these tests also accounted for in the coverage report. This would allow us to leverage Test Intelligence while still maintaining accurate coverage metrics for SonarQube and pipeline gating.

When you add a description to a runtime variable and then when you run the pipeline it only shows the description to the user when you hover over the below icon , which isn’t obvious. Can the UI be changed to make the description show to the user without the need to hover over any icon

I want to use the AWS connector permission in S3 cache/restore step to access S3 however S3 cache/restore step is currently using the permission on the stage infrastructure connector. Expected behavior: When we specify an AWS connector in the S3 cache/restore step, we need to use the permission of AWS connector to access S3 rather than using the permissions defined in the stage infrastructure connector Observed behavior: In order to access S3 currently we don't use the permission of AWS connector configured in the S3 cache/restore step instead we use the permissions of stage infrastructure connector