Feature Requests

Error: The runs.using key in action.yml must be one of: [composite docker node12 node16], got node20

We have a Shell Script Step that sets some output variables as secrets and we are not able to refer it in the same container step.

I would like the ability to create banners via the API. This feature would streamline our processes and allow for more efficient management of banners across different accounts.

Description: The customer is requesting the ability to use more complex node selection behavior within a step group in custom stages, similar to the functionality available in the Kubernetes Build stage. Specifically, they are looking for support for affinity rules and topology spread constraints to enable more advanced scheduling decisions. Use Case: Currently, the customer can only use a basic nodeSelector in the step group of a custom stage. They would like to extend this capability to support more complex behaviors, such as affinity rules and topology spread constraints, to improve pod scheduling in their Kubernetes environments. An example of the behavior they are looking for is the following: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "app" operator: "In" values: - RELEASE_NAME namespaces: - DEPLOYMENT_NAMESPACE topologyKey: " kubernetes.io/hostname " This configuration allows more fine-grained control over pod placement, ensuring that pods are scheduled based on their affinity to other pods, their namespaces, and their topology. The customer would like the option to apply this more complex behavior in step groups within custom stages. Desired Outcome: Extend support for advanced node selection, such as affinity and topology spread constraints, within step groups in custom stages. Allow users to define podAffinity, topologyKey, and labelSelector parameters directly within custom stages. Provide a user-friendly way to configure these advanced features, similar to the way it's done in the Kubernetes Build stage. Reason for the Request: The customer is looking to use more complex scheduling rules to ensure pods are deployed on the most suitable nodes, ensuring better resource utilization and avoiding overloading specific nodes.

We're trying to use the AWS Pod Identity association feature in AWS EKS, but it doesn't seem to be working. Could you please enable support for this feature?

Currently, the Builds tab does not display the repository name associated with each build. Enhancement of the Builds tab to display the repository name associated with each build.

Summary: When fetching configuration files from a GitHub repository, if a secondary rate limit is encountered (resulting in a 403 Forbidden or 429 Too Many Requests response), the system should automatically retry the request a specified number of times ("n" times) before notifying the user of the rate limit issue.​ Details: GitHub enforces rate limits to ensure fair usage of its API. When these limits are exceeded, GitHub responds with status codes 403 or 429, indicating that the client has been temporarily blocked due to excessive requests. To handle such scenarios gracefully, it is proposed that the system:​ Automatic Retries: Upon receiving a 403 or 429 response, the system should automatically retry the request up to "n" times before alerting the user.​ Utilize x-ratelimit-reset Header: The system should read the x-ratelimit-reset header from the GitHub response to determine when the rate limit will reset and schedule retries accordingly. GitHub docs: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#exceeding-the-rate-limit

For any given Harness instance we would like to see the status of Feature Flags affecting that account in a Harness UI, so we don't have to rely on Customer Support to tell us the status of feature flags which impact the way the Harness platform operates.

We have a pipeline where we're deploying a service into our Prod and DR environments. Both environments have its own Values file, which we're specifying in the pipeline as inputs. We want an option to propagate the service from, let's say, Prod deployment stage to the DR deployment stage, and just use the DR-specific Values file in the DR stage. Currently, we're able to propagate the service, but it's using the same set of inputs and Values file as the previous stage. I've illustrated the scenario using att. screenshots. It would be nicer to have this option to propagate a service across stages, while using different Values files for each stage. Thanks!

Hi, I have a pipeline that reads the secrets (username,password,port) for connecting to the servers. These servers are grouped by environment. Ex: Environment A123 has servers server1, server2, server3. Currently, I define the secret like env123_ser1_username, env123_ser1_password. It will be best, if there is a functionality to group the secrets by environment env123.