Fall back to generic env for selectors

[eleftherias]

Summary

When an entity type does not have a specific CEL environment, fall back to the generic environment.

Fix #5375

Change Type

Mark the type of change your PR introduces:

• Bug fix (resolves an issue without affecting existing features)
• Feature (adds new functionality without breaking changes)
• Breaking change (may impact existing functionalities or require documentation updates)
• Documentation (updates or additions to documentation)
• Refactoring or test improvements (no bug fixes or new functionality)

Testing

Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.

Review Checklist:

• Reviewed my own code for quality and clarity.
• Added comments to complex or tricky code sections.
• Updated any affected documentation.
• Included tests that validate the fix or feature.
• Checked that related changes are merged.

[eleftherias]

Note: This PR does not add support for the release entity in selectors. It allows the release entity and the selectors to co-exist in a profile. This followup issue is created to actually support selectors on release entities #5380.

[coveralls]

coverage: 56.818% (-0.02%) from 56.836%
when pulling 669b5fa on fix-release-with-selector
into 58972c8 on main.

[JAORMX]

Note: This PR does not add support for the release entity in selectors. It allows the release entity and the selectors to co-exist in a profile. This followup issue is created to actually support selectors on release entities #5380.

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.

[evankanderson]

Note: This PR does not add support for the release entity in selectors. It allows the release entity and the selectors to co-exist in a profile. This followup issue is created to actually support selectors on release entities #5380.

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.

[JAORMX]

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

[eleftherias]

Note: This PR does not add support for the release entity in selectors. It allows the release entity and the selectors to co-exist in a profile. This followup issue is created to actually support selectors on release entities #5380.

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.

I wrote #5380 to be generic. I'll copy this conversation over to that issue.