Ocean deletion policy | control whether to delete old "deleted" entities
Matar Peles
Examples:
Control whether to:
- delete GitLab PRs that are merged or keep them
- Delete old ArgoCD deployments (based on historyLimit configuration)
- Delete "Done" Jira tasks
The assumption here is that some people would prefer to keep all-time data in Port, and some would rather keep only the live relevant data, so the you should be able to control it.
M
Mark Tarry
+1 for this, with a concrete variant of the problem: live webhook events delete entities that we need to keep as historical records — and
entityDeletionThreshold
does not cover that path.Our case:
the GitHub Ocean integration ingests org members as user entities, which we relate to historic activity (pull requests, usage metrics). When a person leaves the business and is removed from the GitHub org, GitHub sends an organization / member_removed webhook, and the integration deletes the user's entity — destroying the identity link that all of their retained historical data points at. Dependent entities keep existing, but their relation to the deleted user is nulled, so months of correctly-attributed history silently becomes unattributed. The person leaving doesn't un-happen their past activity; we want the entity to become an immutable historical record, not to vanish.The important nuance: we already run
entityDeletionThreshold: 0
, and it made no difference — because that flag governs resync reconciliation only. We verified this against the Ocean source: the GitHub integration's user_webhook_processor.py
unconditionally returns the removed user in deleted_raw_results
on member_removed
, and that live-event delete path never consults entityDeletionThreshold
. So today there is no supported way to keep an entity alive through a live deletion event: no per-kind deletion control, no per-blueprint suppressor, and blueprint unregister permissions don't appear to bind integration tokens.Workaround we're adopting, for anyone with the same problem: the mapping's
selector.query
is evaluated against live-event deletion candidates too, and only items that pass the selector get deleted. The delete path hands the selector the raw REST webhook user object, while upserts use GraphQL-shaped objects — so a selector like has("site_admin") | not
(a key required in the REST webhook user shape, never present in GraphQL results) suppresses the delete while leaving all upserts untouched. It's under test (not yet confirmed), but it also leans on undocumented behaviour, so an official lever would be much preferred.Suggested shape for the feature: a per-kind (or per-blueprint) deletion policy that covers both resync reconciliation and live webhook events — e.g.
deletionPolicy: never | resync-only | live-and-resync
on each resource mapping.Matan Grady
A new option that might help in some cases here was added to our docs
https://docs.port.io/build-your-software-catalog/customize-integrations/configure-mapping#additional-options with the entityDeletionThreshold flag
Matan Grady
Merged in a post:
Retain PR entities after PR is closed.
A
Al-Karim Kerai
Increase the lifespan of Pull request entities ingested using the Azure Devops Ocean Integration. Currently these entities last roughly 7 days from PR close. I'm proposing a way to customise this so that we can set a value for how long they persist. Options could include, 30 days, 3 months, a year, "Don't delete entities on PR close".
This could help aid dashboards that look at closed PR's as currently this data is lost.
Matan Grady
Merged in a post:
Support ingesting merged PRs from Github
Guillaume Hanique
As a healthcare regulated company, I need to be able to see
merged
pull requests that are associated with a JIRA story in Port - and I need to see those PRs dating back since the beginning of time. Currently Port can only ingest
open
Pull Requests, which is not what I need for my regulatory reports.Guillaume Hanique
(This could be implemented with a flag similar to
createMissingRelatedEntities
where, by default, the GetPort.io GitHub App behaves like it has always done).