Feature ideas

Today we have a static and strict small schema we bring about users and teams when integrating with an identity provider (user names, mails, team names) The idea here is to have the whole payload coming from the SSO provider (the schema should be known based on the SSO protocol) and for Port builders to be able to decide what they want to map to the user and team blueprints.

It would be good if the slack integration could pull the slack channels so we could create a blueprint for them and use it in self service forms to give users a dropdown list of channels.

Prometheus often contains a lot of valuable data that we would want to expose to developers via Port, e.g. SLIs like performance, uptime, error rates, costs, alerts It would be nice if Ocean had an integration where we could configure PromQL queries that it could execute periodically and map results back to Port entities

Today when mapping GitHub Users and Github teams, they are mapped separately and cannot be related (can't see which teams a GitHub user is under.) This is something that is logically expected as they are related entities in GitHub itself

Currently the list pull requests api doesn't return the same data as when performing specific GET request to pull request ( e.g. merged, mergeable etc.. properties are missing ) Seems like Github API has a graphQL which supports more properties for resources and advanced search capabilities. https://docs.github.com/en/graphql/reference/objects#pullrequest https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#list-pull-requests

VM ware Ocean Integration

Currently, when fetching ECS resources through the AWS integration, it is possible to retrieve details of an ECS Service but not the status of running containers. This limitation arises because the CloudControl API does not provide access to container-level status and other dynamic data. Introducing a dedicated ECS Service resource kind will allow this information to be retrieved through the ECS API, enabling more comprehensive visibility into the state and performance of ECS Services.

Give me the ability to declaratively define my Port desired state (e.g. blueprints) as k8s resources in yaml. That I can commit to a git repo and have a GitOps tool like ArgoCD automatically pull and submit to k8s. Have a Port k8s controller that installs the required port CRDs to said cluster and when ArgoCD syncs the resources to the k8s cluster the Port controller reconciles the desired state to the actual on app.getport.io Outcome is that we have a declarative versioned state of our Port instance that can be manged and applied following GitOps principles. A "Port" control plane within k8s if you like. A bit like how Crossplane can be used to manage external cloud resource state.

Ocean integration for CheckMarx One API