Feature ideas

Currently, port do not support dynamically re-reading secrets attached to Ocean custom integration. This is already supported in Other Ocean integrations in the following way: Ocean has a built-in mechanism: when this parameter is set, any 401 received from the third-party API triggers Ocean to re-read the token from that file and retry the request - assuming the token has already been refreshed and rewritten there. This allows us to assign external secret and the Ocean integration will use it correctly when rotated outside of the integration. Port should extend this to Ocean Custom integration to work the same way to allow for short lived tokens needed in some APIs.

The Applications API provides a critical capability within Checkmarx by enabling the logical grouping of multiple Checkmarx projects under a unified application construct. This functionality is fully documented in the official reference guide: https://checkmarx.stoplight.io/docs/checkmarx-one-api-reference-guide/branches/main/szojm2v0j748d-applications-service-rest-api Integrating the Applications API into our Checkmarx consumption model is essential for establishing coherent and maintainable context across repositories, workloads, and services. By leveraging this API, we can accurately correlate security findings to the broader application ecosystem, eliminate fragmentation across project-level scans, and ensure that governance, reporting, and compliance activities are performed against a single, authoritative application boundary. Adopting this improves traceability and operational clarity, as well as also strengthens Port's ability to manage risk holistically across the software development lifecycle.

Port’s current Jira integration supports syncing Projects, Issues, Users, and Teams, but does not support additional Jira Agile entities such as Sprints, Boards, Epics, Worklogs, Backlog items, Versions, or other objects available through the Jira Cloud Agile REST API. These objects are essential for richer engineering insights, cross-team reporting, and end-to-end service catalog modeling. Adding support for these Jira resource types would unlock significantly more powerful catalog and automation use cases for Port customers. Primary targets: Sprint Board Epic (as its own blueprint) Worklog Version / Release Nice to have: Backlog containers Components Iterations for Jira Advanced Roadmaps Technical expectations Read support through the Jira Cloud Agile REST API Ability to map fields using Port’s mapping layer (JQ) Relations: Sprint → Issues Board → Sprints Epic → Issues Version → Deployments / Releases / Services Additionally: live events for sprint changes (start/end), board updates, and linked issues.

Currently, when multiple port.yaml files update the same entity, the relations array gets overwritten by the latest update, and any existing relations are lost. It would be helpful if relations from all port.yaml files can be aggregated to maintain a comprehensive list of relationships across projects.

After moving from the old GitHub App to the Ocean-powered GitHub integration (which is supposed to keep full parity), some data is missing: Branch fields that used to be mapped, such as: last_contributor (e.g., . branch.commit.commit.author.email ) last_push / last commit date (e.g., . branch.commit.commit.committer.date )[Map repos] Other repository-related data (e.g., data used for tags). This breaks existing mappings and examples that rely on these fields, even though the new integration is announced as keeping parity with the old one. Impact Existing blueprints, mappings, scorecards, and workflows that depend on last contributor / last push no longer work. Production readiness and activity signals become inaccurate. Migration to the Ocean integration is not a drop‑in replacement and becomes risky. Request Restore branch-level fields in Ocean Make branch data available so we can map: last_contributor (author of last commit on default branch) last_push / last commit date Expose repository-level data at least at the same level as the old GitHub App (including data needed for tags and similar use cases). Add an Ocean-based example equivalent to “Map repositories and last contributor” in the docs. Acceptance Criteria In the Ocean GitHub integration: last_contributor and last commit date for the default branch can be mapped and mirrored to the repository entity. Repository metadata (including tag-related data) is available with parity to the old GitHub App. Documentation includes: An Ocean-based “repositories + last contributor” example.

Allowing data fields like comments, review_comments, commits, additions, deletions, and changed_files in the pull request exporter of the GitHub integration would help measure pull request standards.

SonarQube analysis results can contain a number of additional "metricKeys" - which provide additional context on the analysis results. In particular I'm looking to build a metric which measures the "size" of a Pull Request - taking into account # lines changed, # files changed, cyclomatic complexity and cognitive complexity. All of this information is available in SonarQube (assuming the quality profiles are set up). But the Sonar integration to Port will not currently support fetching these values. When I map the .measures JSON object from the integration, I'm not seeing all of the metrics which are available from Sonar: { "ncloc_change": "0", "coverage_change": "0.0", "violations_added": "3", "violations_fixed": "0", "duplicated_lines_density_change": "0.0" } As far as I can tell, the metric keys are available via the /api/measures/component endpoint: curl --location 'https://sonarcloud.io/api/measures/component?component=PROJECT_KEY&pullRequest=123&metricKeys=cognitive_complexity%2Ccomplexity%2Cnew_lines' \ --header 'Authorization: Bearer SECURITY_TOKEN' { "component": { "id": "...", "key": "PROJECT_KEY", "name": "PROJECT_NAME", "qualifier": "TRK", "measures": [ { "metric": "complexity", "value": "114" }, { "metric": "new_lines", "periods": [ { "index": 1, "value": "558" } ] }, { "metric": "cognitive_complexity", "value": "682", "bestValue": false } ], "pullRequest": "123" } } Having the ability to configure which metric key values we want to ingest would be very useful. Yes, those complexity figures are extremely high - I've generated some terrible code as a PoC for building up our metric! :)

Currently the integration pulls from https://learn.microsoft.com/en-us/rest/api/azure/devops/git/refs/list?view=azure-devops-rest-7.1&tabs=HTTP , but it provides limited metadata. The TFVC endpoints potentially provide additional metadata to help track branch age, creation age etc. https://learn.microsoft.com/en-us/rest/api/azure/devops/tfvc/branches/get-branches?view=azure-devops-rest-7.1&tabs=HTTP

Implement integration level metrics for MTTR and Change Failure Rate.