Feature ideas

Add support for reliably calculating PR size (lines added + lines deleted per PR, with optional configurable file exclusions) across GitHub, GitLab, and Azure DevOps.

In the 'branch' kind, metadata about branch protection rules can be mapped. Having the ability to also map repositories and ruleset metadata would also be helpful.

Today, when updating new objects / arrays of entities the new value overrides the old one. With this feature it will be possible to append values to these properties. Example of Tags property with type of array: Current state: "Tags" : ["tag1"] Ingesting a new tag using the API: "tag2" New state: "Tags": ["tag1", "tag2"]

Add property-level read permissions, adding to the edit permissions for properties that Port already provides.

We’d like to request an improvement to the current search relevance behavior in catalogs. At the moment, search results do not consistently prioritize exact matches, which becomes especially noticeable when users search for common or ambiguous terms. Even when a resource exists with an exact matching identifier, it is often not surfaced at the top of the results, which creates confusion and reduces confidence in search as the primary discovery mechanism. To improve this, we propose adjusting the search ranking logic to better prioritize exact and high-confidence matches. This would significantly improve usability and make it easier for users to quickly find the intended resource without scanning through irrelevant results. Exact match on identifier or (highest priority) Case-insensitive exact match on normalized name Prefix matches (e.g., “action-*”) Partial or substring matches Fuzzy or loosely related matches (lowest priority) This change would make search more predictable and improve overall discoverability, especially in catalogs where resource names can be highly overlapping or ambiguous.

We are going about cataloguing a list of entities (type doesn't matter). These have to be manually discovered in our company and then we add a entity.json to the repo's so they get harvested and ingested into Port. Given the distributed nature of the repos this can take some time. We'd like to first "manually" register these entities in port and then over time sync them to their entity.json metadata as those are merged into various repos. You can see the source of a entity by looking at the audit log screen but I can't surface this on the catalogue table view. So I can't tell which ones are just manually still waiting to be linked to a entity.json etc. Could we have a new column that pulls the most recent audit log change for the entity source. So "API" etc or "Manual"

Currently aggregation properties are only being calculated on number properties and not date properties.

At the moment, when onboarding a data model or when updating an existing one, it is required to go to the blueprint definition and update it according to the additions/changes/removal of properties from the blueprint. It would make data model changes much easier if it was possible for Port to auto-discover the correct data model for the blueprint based on the ingested data. For example: If the key - logs_url is ingested and it matches a URL schema, then add a new logs_url property (if it doesn’t already exist) to the blueprint definition, and set its type to string and format to url . Similar logic can be applied for number , boolean , object and other property types. This auto discovery does have some limitations - for example if a property already exists under a specific schema (i.e. string) and now a pure number is being imported, it will be converted to string, and the schema will not be updated (this is the current behavior today).

At the moment a property which receives a URL-like value (URL, URL list, Embedded URL, etc) only supports values matching the URL schema as defined by JSON schema. This limits some use cases (domains with numbers at the top level, FQDNs without any dots and more)

Right now when you query an entity using API you will get the identifiers of the related entities. It could be helpful to receive the relation objects in the payload instead of just the related object identifier