Feature ideas

Today you can't understand what issues the Github integration has besides the Port API audit log, and issues can happen , for example: 1) GitOps typo is not reflected in Port 2) Wrong mapping is not reflected 3) Sync process is not reflected

TLDR - if Terraform is not creating the port_integration resources, then it should not delete them either ------- As per https://docs.getport.io/guides/all/import-and-manage-integration/ , when setting up a new integration via Terraform, it is necessary to first manually create the integration via the "Builder" UI, and then import this to Terraform. This creates a problem for projects which are subsequently rolled back - e.g. some change has broken a feature in the IDP, potentially unrelated to the new integration. Consider the following sequence: Integration created manually Integration imported into Terraform Changes are applied to the live Port instance (terraform apply) Something in that release is identified as breaking - so we need to roll back to an earlier version Earlier release is deployed - terraform plan & apply is run again, from an earlier version of the code Terraform sees that the integration wasn't present in the earlier version, so it deletes it from both the live portal and the terraform state! Now we're back to square-one, and having to re-create the integration, with a new installation id, all over. Terraform has a convention for resources which aren't directly managed via IaC - Data Sources. I suggest the Port provider should: Offer a "Data Source" to lookup an existing integration, by id / name Update the "port_integration" resource to only manage the config of the integration - not the integration itself

We need the ability to pause and resume data source syncs. While we understand that rate limits determine the sync frequency, having the option to pause and resume would give us control over the order in which data sources sync. This capability is essential as we gradually roll out Port to different teams, ensuring their service data is accurately captured and reviewed before proceeding to the next team.

Currently, Port lacks a command-line interface (CLI) tool for creating blueprints, entities, scorecards, and other functionalities. Introducing such a tool could provide valuable assistance to users.

Today Port hosted integrations are working on a schedule-basis, and ideally it would be better to be able to create real-time integrations hosted in Port.

It would be great to have an AI assistant with the context of previous mappings created in Port that can help me create mappings for my blueprints for each exporter. Even if it won't be 100% precise, it could save me a lot of trouble and time. It can help with writing and creating the mapping independently (e.g., finding relations between entities natively).

Can Port support ingesting AWS costs from the Cost explorer API? https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/Welcome.html There is an official aws plugin for backstage that does this https://github.com/awslabs/backstage-plugins-for-aws/tree/main/plugins/cost-insights The link provided here is no longer valid. https://roadmap.getport.io/ideas/p/aws-exporter-support-cloud-resources-costs

Currently we are having to use the k8s exporter to get Rollout level data. We'd prefer to use the ArgoCD Ocean Integration as it supports Realtime updates through the webhook event approach

Port currently lacks a heartbeat functionality for data sources. This makes it difficult to distinguish between active data sources with functioning exporters and those without proper configuration or deployment. We propose implementing a heartbeat feature to address this issue. Proposal: Implement a heartbeat mechanism for Port data sources. Data sources will send periodic heartbeat signals to Port. Port will monitor these heartbeat signals. Port will display the active/inactive status of data sources based on heartbeat reception. Benefits: Clear visibility of data source status (active vs inactive) Easy identification of data sources with deployment or configuration issues Improved data source management and maintenance Enhanced system reliability and troubleshooting This feature will enable users to quickly identify inactive data sources, allowing them to either remove them from Port or address exporter deployment issues, thus improving overall system health and data accuracy.

Current scenario: Integrations are calculating the payload based on the mapping YAML, and they send all properties that are being mapped. Suggestion: Add the ability to drop the key in the mapping configuration. This way, the integration will not override existing keys in Port, while still having the ability to map data dynamically. Example: protected: if (.branch.protected != null) then .branch.protected else {DROP_KEY} end If the object contains the branch data, then map it to the entity, and if it does not a custom operation will drop the key from the payload, not overriding the current data.