Feature ideas

Summary Track PR Rework as a key engineering metric - the number of review cycles or post-review commits before a PR is approved. Integrations Should support the following key SCMs: GitHub GitLab Azure DevOps

The native GitLab integration in Port does not currently expose the duration field for pipeline entities. We'd like this field to be supported natively. The current pipeline kind mapping fetches data from the GitLab list pipelines endpoint (/api/v4/projects/:id/pipelines), which returns fields such as status , created_at , updated_at , and web_url . However, the duration field is only available on the individual pipeline detail endpoint ( /api/v4/projects/:id/pipelines/:pipeline_id ). What we need: For each pipeline fetched during resync, we'd like Port to also retrieve the detailed pipeline record so that the duration field is available for mapping.

Currently the ADO kind for Test Runs containers both Code Coverage and Test Results. These should be separate kinds.

Add a native Port integration with Harness to sync cost and deployment data into the Port catalog. Key capabilities needed: > Pull cost data (ideally at resource/ARN level) into Port entities > Enable cost attribution by service and team ownership > Surface Harness cost visibility alongside other catalog data without requiring expert-level Harness dashboard access This would allow platform teams to tie cloud spend directly to service owners in Port, driving cost accountability without requiring developers to navigate Harness directly.

The Snyk Target portion of the port hosted Snyk integration is not returning empty targets (targets with no projects). The default behaviour of the Snyk api appends the exclude_empty=true query param to the next page link. I'd like there to be a way to tell the integration not to exclude_empty targets. We want a way to be able to see if a repo is in Snyk or not, but we have repos in snyk that don't have projects. Maybe it can be an additional selector?

Customers using the Aikido Ocean integration needs team ownership surfaced at the issue group level, not just on individual issues. Their teams use included_paths to define responsibility, and while individual Aikido issues map correctly to teams via affected_file, issue groups only expose repository-level data — so the same matching can't be applied. The natural workaround (relating issue groups → child issues → teams via mirror properties) is blocked by the 500-entity search relation cap, since groups can have hundreds of child issues. A simple SET aggregation also doesn't meet their needs — because individual issues can belong to multiple teams, they need a distinct list of teams per issue group, making this a true many-to-many relationship. Requested: Add a native team dimension to the Aikido integration by leveraging Aikido's own team→issue group mapping: GET /api/public/v1/teams GET /api/public/v1/open-issue-groups?filter_team_id={ team.id } This would expose a team_issue_groups resource (or equivalent relation on issue groups) with the distinct set of owning teams per group — modelled as many-to-many. Without this, the customer is forced to build and maintain an external scheduled aggregation job.

If you could support the gitlab graph api in the way you do for GitHub it would be great as a lot more information is exposed than the standard APIs. Thanks

Currently, pipelines rely on a generic webhook trigger with a shared endpoint. We'd like support for Jenkins' native "Trigger Build Remotely" option at the pipeline level, allowing each pipeline to have its own authentication token and a unique trigger URL in the format: JENKINS_URL/job/<JOB_NAME>/build?token=<TOKEN> This would allow different backend services to target specific pipelines directly — without shared endpoints or custom routing logic. Desired Behavior Expose a "Trigger Build Remotely" option in pipeline settings. Allow a per-pipeline authentication token to be defined. Each pipeline gets its own unique, independently callable trigger URL.

Current Behavior: When a Port integration is deleted, its associated secrets stored under Credentials → Secrets are not automatically removed. These stale secrets persist and can cause a "secret already exists" error if a user attempts to recreate the same integration type later. Desired Behavior: When an integration is deleted, Port should either: > Automatically delete all secrets associated with that integration, or > Display a prompt/warning during the deletion flow reminding users to manually clean up the associated secrets to avoid conflicts on re-creation.

With the new AWS Integration, we would like to ingest data from AWS CodeBuild, AWS CodeDeploy and AWS SES.