-
Greetings, I encountered a minor issue with matchpatterns. Specifically, I'm attempting to replace every string that starts with "^something" with other text. However, it appears that the "^" character is being treated as a regular character rather than indicating the start of a line. Here's a snippet of what I'm trying to achieve: sample_change:
name: Update string
kind: file
scmid: gitlab
sourceid: sample
spec:
file: "main.yml"
matchpattern: "^something_"
replacepattern: "others_" Regrettably, I'm receiving an error message stating:
Oddly enough, when I use the sed command in the command line, I get the desired results: sed -i.bcp -e "s|^something_|others|g" main.yml I'd like to note that the "^" character is recognized by Go's regexp library (re2). Have I overlooked something? I've been troubleshooting this issue since yesterday. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 8 replies
-
Could you try with the following and compare result? sample_change:
name: Update string
kind: file
scmid: gitlab
sourceid: sample
spec:
file: "main.yml"
matchpattern: |-
^something_
replacepattern: "others_" which indicates a literal multiline with no newline at the end (https://yaml-multiline.info/) in YAML. The goal is to remove the YAML parser from the equation |
Beta Was this translation helpful? Give feedback.
-
Thanks for opening the issue.
I don't understand why because as far as I know "^" is not a special character interpreted by YAML or Go templates |
Beta Was this translation helpful? Give feedback.
-
Also based on your example, the way you use the sourceid will not work,. probably better to use something like
Where you use the dynamic function |
Beta Was this translation helpful? Give feedback.
-
In this case I don't know if the problem is a bug or by design :-D but there is definitely room for improvement. |
Beta Was this translation helpful? Give feedback.
Hello @olblak,
We applied the (?m) pattern to achieve multiline matching, and it effectively resolved the issue.
We realized that the "^apache2" pattern was only attempting to match the first line, which caused errors on our end.
After carefully studying the golang expression, we identified the correct regular expression to use.