Custom properties predicate

[south-mer]

Before this PR

Custom properties are not supported in predicates.

After this PR

Custom properties are supported in predicates, implemented in the way as proposed in #1029 (comment).

Possible downsides?

New predicate are not active unless they are used in the policy, so there should be no negative impact.

Screenshots

Some screenshots when testing the feature to cover the "testing" of ConditionPhrase and ReverseSkipPhrase that is not covered by policy/predicate/custom_properties_test.go

match

nomatch

empty

[changelog-app]

Generate changelog in changelog/@unreleased

Type (Select exactly one)

• Feature (Adding new functionality)
• Improvement (Improving existing functionality)
• Fix (Fixing an issue with existing functionality)
• Break (Creating a new major version by breaking public APIs)
• Deprecation (Removing functionality in a non-breaking way)
• Migration (Automatically moving data/functionality to a new system)

Description

Add predicates for custom repository properties: custom_property_is_not_null, custom_property_is_null, custom_property_matches_any_of, and custom_property_matches_none_of

Check the box to generate changelog(s)

• Generate changelog entry

[south-mer]

@bluekeyes hello, could you let us know if this implementation matches the design as suggested at #1029 (comment), and if any other modifications are needed?

[bluekeyes]

Sorry, I was unavailable last week, but this is on my list to review this week. Thanks for submitting the PR!

[bluekeyes]

Thanks for submitting this! I had a few comments related to how the details messages are produced, but I think the core logic of the predicates all looks good.

[bluekeyes]

The current structure for these messages will render a bit awkwardly. I think there are two options to improve it:

1. Use the predicate to populate the values and omit the condition values:

   ValuePhrase:     "custom properties",
   Values:          pred,
   ConditionPhrase: "exist",

   This is the simplest, but does not show the actual properties that are set on the repository.

2. Adjust the messages so that you can show all of the actual properties:

   ValuePhrase:     "custom properties",
   Values:          formatCustomProperties(customProperties),
   ConditionPhrase: "contain",
   ConditionValues: pred,

I prefer the first option. I think the message is clearer and the actual values of the properties are not as important when the predicate check only if they are present or not.

[south-mer]

I chose the second option in baf70ef, because it might be a bit confusing to debug without the current values.

If the first option is strongly preferred, I can switch to it.

[bluekeyes]

This message should also be updated in the same way as the message for CustomPropertyIsNotNull, but adding ReverseSkipPhrase: true.

[south-mer]

I chose the second option in baf70ef, because it might be a bit confusing to debug without the current values.

If the first option is strongly preferred, I can switch to it.

[changelog-app]

✅ Successfully generated changelog entry!

What happened?

Your changelog entries have been stored in the database as part of our migration to ChangelogV3.

Need to regenerate?

Simply interact with the changelog bot comment again to regenerate these entries.

[south-mer]

Thank you for the review. I will fix the conflict, address the issue and then request another review.

[bluekeyes]

Thanks! We have some other pending features that I need to review and test, but I'll try to make a release with these new predicates soon.