Support path key prefix selection in Config #62

status: discussion

Finalised Approach

# Introducing regex field in path similar to allIndexes we have currently
- path: [metadata, annotations, {regex: "^cert-manager[.]io"}]

Tasks

Support regex as the new filed in config path
Made changes in apply() method of Copy mod, remove mod and overlayContract Mod and write method to parse regex and loop over the fileds to see what all matching with regex
This change will get applied in all the rules (rebaseRule, ownershipLabelRules, OwnershipLabelRule, labelScopingRule, DiffMaskRule, TemplateRule) will be supporting regex in just rebaseRule
Testing and adding e2e test cases

Proposal 1: Support for Regular Expression

Ability to define regex will give lot of upper hand to consumers instead of limiting the functionallity to prefix, suffix, etc

How we figure out that in path which one is regular expression and which is the value user want to match exactly(old flow)?

I can see couple of options here -

Approach 1 -

Introducing a new field pathRegex in which user can define path with regex

- pathRegex: [metadata, annotations, "^cert-manager[.]io"]

Advantage

Will be backward compitable and the existing behaviour of path doesn't change

Approach 2 -

Giving regex: prefix in a string to identify the regex

- path: [metadata, annotations, "regex:^cert-manager[.]io"]

Advantage

Will be backward compitable and give the clarity as to which exact string should parse as regex

Disadvantage

maybe a hacky thing and have to loo

Approach 3 -

While iterating though path first check if there is any key/value exactly match with the given string(old flow) if not then validate regex if its valid then match the resources with the given regex

- path: [metadata, annotations, "^cert-manager[.]io"]

Advantage

Didn't need to explicity mention while putting regex will be much cleaner

Disadvantage

If user is not aware that we fallback to regex if the given string does not match fully then it lead to match the resources that user doesn't want to match

Approach 4 -

~~Using some identifiers to confirm that user is trying to match resources with help of regex. There can be multiple formats to support it~~

Format 1: Introducing regex field in path
- path: [metadata, annotations, {regex: "^cert-manager.io"}]

# feel free to add any other format here that you think will be more better

Advantage

User is always aware of the end result~~

Approach 4 -

Proposal 2: Support for different type of keys

Supporting some of the limited functionality that are commenly used such as prefix, suffix etc

rebaseRules:
- path: [metadata, annotations, {prefixed: "cert-manager.io/"}]
...

rebaseRules:
- path: [metadata, annotations, {suffixed: "cert-manager.io/"}]
...

Open Question -

While having regex in yaml can it cause parsing issues