# Support path key prefix selection in Config #62 status: discussion ### Finalised Approach ```yaml # Introducing regex field in path similar to allIndexes we have currently - path: [metadata, annotations, {regex: "^cert-manager[.]io"}] ``` #### Tasks 1. Support regex as the new filed in config path 2. 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 3. This change will get applied in all the rules (rebaseRule, ownershipLabelRules, OwnershipLabelRule, labelScopingRule, DiffMaskRule, TemplateRule) will be supporting regex in just rebaseRule 4. 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 <!-- -- Prefix ``` rebaseRules: - path: [metadata, annotations, "^cert-manager.io"] ... ``` -- Suffix ``` rebaseRules: - path: [metadata, annotations, "certificate-name$"] ``` -- Contain string ``` rebaseRules: - path: [metadata, annotations, "manager.io/*"] ``` -- Full string match ``` rebaseRules: - path: [metadata, annotations, "^certificate-name$"] ``` --> ##### 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 - <!-- Still figuring out in the codebase that if we would be needing any identifier for regex or we should first check if there any key exists with the name, if not we just compile the regex check if its valid then we should try to match it with the resources --> ### 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