Feature Requests

Currently we need to either disable API access on the Git connector or disable the native Git clone step to disable the status check during CI stage execution however this is resulting in missing commit/PR details in the execution UI. We need to have a separate option in the UI to disable sending the status check during CI stage execution without affecting the commit/PR details in the execution UI

Currently Harness Service Account User is enable with PAT token. We have instances where business wants to use this Harness Service Account user to have SSH Authentication to clone the Harness Git repos from respective Infrastructure servers to execute Ansible playbooks.

Summary Currently, when a component's catalog-info.yaml is updated with new metadata (e.g., adding a Slack channel, updating an owner, or adding a repository tag), the associated Scorecard checks do not reflect these changes until a user manually navigates to the UI and triggers a "Rerun Checks" action. This proposal requests an automated trigger to re-evaluate scorecards whenever the underlying Catalog entity is updated. The Problem Stale Data: Scorecards often show "Failing" grades for checks that have actually been resolved in code, leading to a lack of trust in the dashboard. Manual Overhead: Developers must remember to manually trigger a refresh, adding unnecessary steps to their workflow. Delayed Feedback: There is a "lag" between fixing a metadata issue and seeing the visual confirmation of that fix. Proposed Solution Implement an event-driven refresh mechanism. The system should listen for lifecycle events from the Catalog (specifically EntityUpdated or CatalogUpdate) and automatically queue a scorecard re-scan for the affected entity.

The goal is to move away from static, manual-entry text fields—which are prone to "fat-fingering" and input errors—and move toward a real-time, validated lookup component. Core Functionality Asynchronous Lookup: The UI component should perform an asynchronous GET request to a customer-defined REST API endpoint as the user types. Search Debouncing: To prevent overwhelming the external API, the request should only trigger after a specific character threshold (e.g., 3 characters) or a short delay (300ms) in typing. Key-Value Separation: * Display Value: What the user sees (e.g., "Payment-Processing-Service"). Stored Value: The actual unique identifier (e.g., "V-99827") that is passed into the underlying YAML and used for provisioning. Validation Enforcement: The workflow should prevent submission if the user tries to enter a value that was not returned by the API search, ensuring that only "existing and valid" entities are used.

Core Problem The current UI renders arrays by generating a new, full-width row for every single item added. When a workflow involves multiple inputs (e.g., several environment IDs or service tags), the form becomes excessively long. This "vertical bloat" makes it impossible for users to see the entire form at once and complicates the review of entered data. The Requirement A single input container that "tokenizes" multiple entries into compact, removable pills. Behavior: When a user types a value and presses Enter, the string is converted into a Tag (Pill). Spatial Layout: Tags must wrap horizontally within a single field. The field should only expand its height if the horizontal line is full, rather than creating a new row for every single value. Editing: Each tag must include a clear "X" button for instant removal. Validation: The system should support entering a value, pressing enter, and immediately typing the next one without manual clicks between rows. Specific Use Case In workflows with nested arrays (arrays within other arrays), the current vertical expansion causes a compounding effect where the UI becomes "unbounded." Condensing these into tags ensures even complex, multi-layered forms remain visible within a single screen view.

Problem Statement "Sometimes the color mismatching looks completely different. It should just blend in so the user doesn't have doubts." Currently, there is a significant visual disconnect between the core Harness UI and custom-built Catalog plugins. Because developers must build their own design and CSS styling from scratch, plugins often fail to match the Harness aesthetic. This lack of synchronization creates a fragmented user experience, making custom plugins feel like external, untrusted additions rather than native features. Developers are currently forced to "guess" styles, leading to: Color Mismatching: Inconsistent palettes between the platform and the plugin. Theming Friction: Difficulty supporting Light/Dark mode transitions automatically. Design Silos: High effort required to recreate standard Harness components (buttons, cards, inputs). Proposed Solution The introduction of a Standardized Plugin Boilerplate and Theme Provider SDK. This solution will provide a "Harness-native" foundation for all new plugins, ensuring they inherit the global design system automatically. By exposing Harness design tokens and providing a pre-configured starter kit, developers can focus on plugin functionality while the UI "blends in" by default. Key Functional Requirements Universal Design Tokens: Provide a library of CSS variables (e.g., primary colors, surface backgrounds, font scales) that stay updated with the Harness brand. Theme Provider Wrapper: A wrapper component that detects the user's active theme (Light/Dark/System) and propagates those styles to the plugin's CSS context. Ready-to-Use Boilerplate: A CLI or repository template that comes pre-integrated with the Harness Design System (HDS) styling bridge. Standardized Component Library: Access to lightweight, pre-styled UI elements (buttons, typography, tables) that match the platform’s look and feel. User Benefits Seamless UX: Users experience a cohesive interface where plugins look and feel like native parts of the Harness ecosystem, increasing trust and adoption. Accelerated Development: Developers save hours of CSS work by using a "plug-and-play" boilerplate instead of recreating styles from scratch. Future-Proofing: When the Harness UI evolves or updates its brand colors, plugins utilizing the boilerplate will update automatically without requiring manual code changes. Reduced Cognitive Load: A consistent UI reduces the learning curve for users interacting with new custom-built features.

Proposed Solution We propose a two-tier enhancement to the IDP: A Component Framework: A way to build and publish "Custom Pickers" as reusable libraries. A Visual Canvas: A drag-and-drop interface (similar to Power Platform or Harness) that allows users to assemble workflows using these pre-defined components. Key Functional Requirements Custom Picker Framework: * The ability to define a picker once (e.g., a "Service Selector" or "Cloud Region Picker") and publish it to a central library. Standardized APIs to fetch data into these pickers (e.g., connecting to internal CMDBs or Cloud providers). Visual Drag-and-Drop Editor: A canvas-based UI where users can see an "Inventory of Things" (the components). Ability to drag components onto the stage to generate the underlying YAML automatically. Consistency with Existing Tooling: Mirror the functionality of the existing Project and Org pickers but allow for user-defined logic. User Benefits Efficiency: Reduces the time to create a new workflow from hours to minutes. Governance: By publishing pickers as a library, we ensure every team is using the same approved data sources and input formats. Lower Learning Curve: Users who aren't "YAML-fluent" can contribute to and build their own automation.

Enable tag-based RBAC controls for templates and other Harness resources, similar to the existing tag-based RBAC model available for pipelines, to allow granular access control without requiring pre-created resources. Problem Statement: Teams need to grant access to subsets of templates at the same hierarchy level, especially at the account scope, without exposing all templates or requiring platform teams to pre-create them. Current RBAC limitations: Access can only be granted to all templates at a level or to specific existing templates Users cannot create new templates without prior access to a specific template Platform teams must bootstrap empty templates to grant access, creating operational overhead When Terraform manages resource groups, bootstrapping templates outside Terraform causes configuration drift Automating template creation via IDP can also modify resource groups, further increasing drift risk This creates a "chicken-and-egg" problem where users cannot create templates because they lack access, and access cannot be granted without an existing template. Current Workaround Some teams use Policy as Code (OPA) to enforce tag-based governance: Require tags on templates Restrict allowed tag values Map tags to user groups allowed to modify templates While effective, this approach: Moves access control from RBAC to policy enforcement Adds complexity and an additional governance layer Is not consistent with native RBAC behavior Proposed Enhancement: Introduce native tag-based RBAC for templates and other Harness resources, similar to pipelines. Desired Capabilities: Grant permissions based on resource tags rather than specific resource instances Allow users to create templates if they apply permitted tags Restrict modification access to resources with specific tags Apply consistently across Harness services, not just pipelines

Requesting support for queuing a triggered build behind an in-progress build rather than aborting it.

Allow looping strategies like matrix, repeat and parallel when invoking a child pipeline as a stage inside a parent pipeline.