Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support generic entity instance in selectors #5380

Open
eleftherias opened this issue Jan 29, 2025 · 1 comment
Open

Support generic entity instance in selectors #5380

eleftherias opened this issue Jan 29, 2025 · 1 comment
Labels
P1 Fix Soon: High priority items that should be considered in the next Sprint planning cycle

Comments

@eleftherias
Copy link
Contributor

This in turn will add support to the release entity in selectors.

With the current implementation, if a selector is added to the release entity, for example:

selection:
  - entity: release
    selector: entity.name == 'test-org/public-repo/v8'

Then it fails with the message

No converter available

because the selector logic is written per entity type and there is no support for releases, see

func newConverter(entType minderv1.Entity) toSelectorEntity {
switch entType { // nolint:exhaustive
case minderv1.Entity_ENTITY_REPOSITORIES:
return repoToSelectorEntity
case minderv1.Entity_ENTITY_ARTIFACTS:
return artifactToSelectorEntity
case minderv1.Entity_ENTITY_PULL_REQUESTS:
return pullRequestToSelectorEntity
}
return nil
}

Since we are moving towards having a more generic entity type, using the EntityInstance type, we should also make the selector logic more generic.

@eleftherias eleftherias added the P1 Fix Soon: High priority items that should be considered in the next Sprint planning cycle label Jan 29, 2025
@eleftherias eleftherias moved this to Backlog in Planned Work Jan 29, 2025
@eleftherias
Copy link
Contributor Author

Copying conversation from #5379

Can we have a general way for entities to use selectors via properties? That way we wouldn't have these entity specific pieces of code.

Hmm -- the way I see it is:

  • Entities need to be able to expose a set of properties (e.g. for a GitHub release (which is associated with a repo), this would include both release-specific properties (like the tag) as well as repo properties (such as whether the repo is public).
  • Selectors need to be able to operate over properties like repository.is_private = true and have that apply to not just repositories, but entities which are linked to a repository, like PRs and releases.

Does that make sense? If so, I'd like it to be required (e.g. compile error if not implemented) for entities to implement enough of "expose properties" to support selectors. I think that could end up with a generic "entity" and properties extracted from it, or a few other routes.

Entities already all should have Properties, and the protobuf provides a GetProperties function. So... we should already be able to generalize

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 Fix Soon: High priority items that should be considered in the next Sprint planning cycle
Projects
Status: Backlog
Development

No branches or pull requests

1 participant