Summary
Explore extending the Referrer / discovery API (ReferrerService.DiscoverPrivate and DiscoverPublicShared) to allow filtering referrer lookups by project name and project version, in addition to the current digest + kind filters.
Motivation
Today discovery resolves a referrer purely by content digest (with an optional kind to disambiguate). When the same digest appears across multiple projects/versions, callers cannot scope the lookup. Allowing project name and project version filters would let consumers narrow discovery results to a specific project context.
Current behavior
- Proto:
app/controlplane/api/controlplane/v1/referrer.proto — requests only accept digest, kind, and pagination.
- Service:
app/controlplane/internal/service/referrer.go — DiscoverPrivate/DiscoverPublicShared.
- Biz:
app/controlplane/pkg/biz/referrer.go — GetFromRoot, GetFromRootUser, GetFromRootInPublicSharedIndex. Filters are expressed via GetFromRootFilter functional options (WithKind, WithVisibleProjectIDs, WithPublicVisibility).
- Data:
app/controlplane/pkg/data/referrer.go — GetFromRoot/doGet build Ent predicates over the referrer→workflow→organization/project relationships.
Notes on feasibility
- Referrers are linked to workflows, and each workflow carries
ProjectID and OrganizationID (see hydrateWorkflowsInfo). Filtering by project name is therefore tractable: resolve project name → project ID(s) and add a workflow/project predicate, reusing the existing project-scoping plumbing (WithVisibleProjectIDs).
- Project version is not modeled as a direct edge from referrer/workflow. It currently only appears in the attestation referrer's
Metadata map (project, projectVersion keys populated in extractReferrers). Versions are associated with workflow runs, not referrers directly, so version filtering needs a design decision (metadata-based filter vs. introducing a referrer↔version relationship).
Scope to define
Summary
Explore extending the Referrer / discovery API (
ReferrerService.DiscoverPrivateandDiscoverPublicShared) to allow filtering referrer lookups by project name and project version, in addition to the currentdigest+kindfilters.Motivation
Today discovery resolves a referrer purely by content digest (with an optional
kindto disambiguate). When the same digest appears across multiple projects/versions, callers cannot scope the lookup. Allowing project name and project version filters would let consumers narrow discovery results to a specific project context.Current behavior
app/controlplane/api/controlplane/v1/referrer.proto— requests only acceptdigest,kind, andpagination.app/controlplane/internal/service/referrer.go—DiscoverPrivate/DiscoverPublicShared.app/controlplane/pkg/biz/referrer.go—GetFromRoot,GetFromRootUser,GetFromRootInPublicSharedIndex. Filters are expressed viaGetFromRootFilterfunctional options (WithKind,WithVisibleProjectIDs,WithPublicVisibility).app/controlplane/pkg/data/referrer.go—GetFromRoot/doGetbuild Ent predicates over the referrer→workflow→organization/project relationships.Notes on feasibility
ProjectIDandOrganizationID(seehydrateWorkflowsInfo). Filtering by project name is therefore tractable: resolve project name → project ID(s) and add a workflow/project predicate, reusing the existing project-scoping plumbing (WithVisibleProjectIDs).Metadatamap (project,projectVersionkeys populated inextractReferrers). Versions are associated with workflow runs, not referrers directly, so version filtering needs a design decision (metadata-based filter vs. introducing a referrer↔version relationship).Scope to define