-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use full yaml parsing for more correct comment stripping #585
Conversation
Thank you for your contribution @Elliot-Roberts! May you share the chunk of your
Your solution seems better than the regex that I'm using so I'm going to merge this PR, please check my review comments, thank you! |
About where the regex fails: it looks like when there is a Using part of the test case I wrote as an example: a1: '123!@# not a comment' It first finds all matches for a1: '123! |
Thank you @Elliot-Roberts! |
Sure thing, and thanks for the tool! It's been very nice. |
Hi, I was encountering a bug where an
inlineManifest
added via patch in mytalconfig.yaml
was ending up malformed in the node config generated by talhelper.For example, my patch had this line:
- '--log-format [%Y-%m-%d %T.%e][%t][%l][%n] [%g:%#] %v'
Which was being modified to:
- '--log-format [%Y-%m-%d %T.%e][%t][%l][%n] [%g:
I tracked the issue down to the yaml comment stripping phase: the current regex is a bit overzealous and thought there was a comment in that string. Seeing the
// FIXME use better logic than regex
comment there, I thought I'd take a shot at improving it.The approach I went with is a little heavyweight. The input is fully parsed into a yaml AST, operated on, and then re-rendered to bytes. This is probably best for correctness, but I would also be up for writing something lighter if preferred. I can think of a few ways of just modifying the regex to fix my case, for instance.
There are also behavior changes beyond unambiguous bug-fixing, which should be considered before merging.
"Comments" that are within multiline strings that happen to be embedded yaml are no longer stripped (because they are actually part of the content of the string). It could cause problems if anyone was relying on "commented out" code in strings being excluded from environment variable substitution. For example, this will error when
MYENV2
is not defined:While semantics should be preserved, sometimes style choices are not.
The output of
stripYamlComment
will always be indented with 4 spaces, regardless of input style.Multiline strings are sometimes converted to double quoted ones. For instance, when they contain lines with trailing whitespace:
will be turned into:
(seems intentional, but I am not entirely sure why)
Most likely some other things I haven't thought of.
This might constitute a version change?
Thanks for your consideration and your work on this tool!