Feature Requests

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.

When using ui:field: HarnessAuthToken in an IDP workflow input form, the token appears masked correctly in the review screen. However, if the token is passed to a backend pipeline through a trigger pipeline step, the token is exposed in plaintext within the pipeline execution logs under the Inputs section. This does not happen with fields that use ui:field: Secret, which are masked end-to-end as expected.

Trying to output an error message to the Internal Developer Portal (IDP) execution view if pipeline fails. It shows the output message only if the pipeline succeeds but unable to do so for explicit pipeline failure.

n the IDP, the catalog page columns should be configurable for users, for example users should be able to hide Lifecycle column or Owners columns from the page

Currently, workflow execution in IDP only supports the default branch, which limits flexibility when teams want to maintain and test different versions of workflows across multiple branches (e.g., dev, staging, release). Adding support to execute workflows from non-default branches would enable branch-based development and testing, allow safer validation before merging to default, and better align with GitOps practices where branches represent different environments or versions.

Details: After upgrading from IDP v1 to v2, all our catalog templates were converted to Inline templates. We’re now migrating them to a remote repository using the "Move to Git" feature. Our organization enforces a Git commit policy that requires including a JIRA story number in every commit message. Currently, when using the "Move to Git" option in IDP, there is no way to specify a JIRA story number or customize the commit message. Request: Please enhance the "Move to Git" workflow to allow users to: Enter a JIRA story number. Customize the commit message before committing.

Dow ehave any Patch API for updating the Entity , so that we can update only the needed metadata to the existing catalog. Current post call cleares the old entries and creates entry for the current call

Please enable feature flag IDP_ENABLE_WORKFLOW_FORM_CONTEXT so that i can use Form context on the IDP workflow

As a user, I would like to be able to add my components in the IDP sidebar for quick user interactivity.

Hi Team, We would like to have ability to configure ADR as a selection in my side bar navigation menu in IDP.