Feature Requests

We'd like a method to be able to see EOS/EOL status a lot easier. Currently, the process is to look at a docs page which is not linked to in the Harness Console and is not frequently updated We need a method so that our teams can be informed ahead of time. Here are some suggestions: API to allow for tracking of the EOS/EOL status of each delegate version. This can be a list with the information UI Changes/backend changes - Show Minimum supported version/last version available for EOS, and others that are EOL - Flag delegates with an icon for EOS and EOL status Notification process - customers to be notified about delegates that go into EOS and EOL status - warn customers a month in advance about the EOS EOL Status

We need to setup a delegate configuration which is multi-region. We need to run delegates in 2 EKS clusters in two AWS regions. In each EKS cluster there will be a scalable set of delegates (say min 4 max 8) and all these delegates will use the same tag. User CI load for all users of Harness in our Harness account will use the same tag. We expect the CI load to be spread across all the delegates across the two regions. We had set this config up but the delete/cleanup tasks were not going to the same cluster where the work task was assigned to. This caused pods to not get cleaned up, resulting in resource leaks and cluster running out of resources. We have been running on a single cluster for a while and this is not an acceptable config for a critical service like CI/CD which is used across the many teams. We would like to use this multi-region ASP.

Segregation of CI and CD pipelines for easy maintenance and better readability. Folder structure for maintaining CI and CD pipelines based on services or tech stack.

Feature request as suggest by Harness team to enable system level error retry mechanism for the below failures : - Pod eviction Failure to connect to addon client Connectivity errors between delegate and ci lite engine ref : https://support.harness.io/hc/en-us/requests/72479?page=1

As part of the JWT/OIDC authentication for vault allow us to enhance the claims to include the environment id. This is required since we would like to make the scope more granular in order to allow production secrets to only be available to production environments. Additionally prod1 env should not have access to prod2 secrets as part of the pipeline. Include a claim in the JWT payload for the current environment id account/{account_id}:org/{organization_id}:project/{project_id}/{env_id} Similar to feature flag PL_OIDC_ENHANCED_SUBJECT_FIELD but with extra field. https://developer.harness.io/docs/platform/secrets/secrets-management/add-hashicorp-vault/#option-jwtoidc-auth

We want to create workspace templates for team to use to create workspace easily for each service to bring up infra. so i need just user input for directory path when they create workspace using the created workspace template. Creating a template for a repo and one directory doesnt serves a purpose. it only give user who uses template prefilled fields with no edit options.

Functionality that allows control of account and org-scoped connectors and delegates at the project level, similar to how resource groups and roles work

Allow customers to see the first / last 4 characters of an API token to ensure they know which API key has been used before.

Many teams use not only CI when deploying infrastructure, and we need to enable (and enforce via OPA) teams to scan their IAC before deploying. Currently there is no way to perform Wiz Native scanning or using Custom Scan Ingestion steps (two different solutions) within CD or Custom Stages. We need teams to be able to view their vulnerabilities regardless of the stage they are deploying.

In the harness docker runner the location of the docker socket and docker binary is hard coded into the program docker sock: https://github.com/harness/harness-docker-runner/blob/master/engine/engine.go#L27 docker bin: https://github.com/harness/harness-docker-runner/blob/master/setup/setup.go#L57 Having these values hard coded makes it more difficult to run this with an alternative docker installation like lima or with docker installed through package managers like homebrew. please make these two values overridable with environment variables or cli arguments