Feature ideas

Having a built-in feature to sync Port’s service catalog directly with incident.io would be beneficial, as it would help in removing the dependency on external CI/CD pipelines.

We use https://www.anodot.com/ for FinOps and would like to have its integration with Getport.

Port's SNOW integration supports Catalog and Incidents today. The need is to add documented support for Vulnerabilities and Release Management

Currently, Port's K8s exporter only supports exporting entities from resources inside the k8s cluster. When Port's "Entities" CRD was introduced, it allowed mapping and ingesting any entity from your K8s environment, including non-k8s entities. To further enhance this ability, we want to be able to create blueprints defined as CRDs as well. This means we need a CRD defining a blueprint, and to allow the exporter to also create blueprints inside of Port.

Today our DORA metrics and others are in Kusto. We would like to be able to create a dashboard with data that we query using Kusto

For the GitHub checks in the GitHub app for file kind, some scenarios are not being handled by Port API: 1) When the identifier is null, Port auto-generates an identifier with a UUID so no error is raised from Port API, even though we want to enforce it 2) When you want each field in the yaml to fit to a property in Port, 1:1, and use all the data of the file. That is when you want any typo in the yaml keys to raise an error 3) For a scenario where you want Port to make sure all the properties of the entity are mapped, and null for a property is not expected (instead of making fields required)

Add support for custom properties https://docs.github.com/en/rest/repos/custom-properties?apiVersion=2022-11-28#get-all-custom-property-values-for-a-repository

Enhancing the JIRA integration by including issue changelog data would significantly improve its functionality. A more flexible approach would be to allow ocea-jira to support a custom configuration that translates into a JIRA API expand parameter value, enabling users to tailor data retrieval based on their needs. The business case for integrating the JIRA issue changelog is to enable accurate tracking of issue transition times across different statuses. Currently, only created and resolved timestamps are available, which does not reflect the true lead time—especially when an issue remains in the backlog for an extended period due to low priority. By incorporating changelog data, the integration would provide a more comprehensive view of issue lifecycle progression. A mapping configuration could then be leveraged to calculate the time spent in each status, ensuring more precise workflow analytics and performance insights. This enhancement would significantly benefit teams by improving cycle time analysis, bottleneck identification, and overall efficiency tracking within JIRA.