-
Notifications
You must be signed in to change notification settings - Fork 143
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
Add ability to escape variable expansion in policy #5035
Conversation
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
Quality Gate failedFailed conditions |
Seems SonarQube is mad about the generated code from antlr, not from the code added. |
I'm okay with force merging this if we are getting the approval from code reviewer, @ycombinator is probably sharing my thoughts here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
func (v *expVisitor) VisitExpEVariable(ctx *parser.ExpEVariableContext) interface{} { | ||
// escaped variables are not allowed in Eql conditions | ||
// they should be wrapped in a constant to be allowed as a valid string in the expression | ||
v.err = errors.New("escaped variable $${ is not allowed") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nitpick) Would this error message be clear in the logs that this is not allowed in a condition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the condition checker adds that context.
Force merging as this PR contains a lot of generated code and SonarQube is not able to exclude it. |
What does this PR do?
Adds the ability to a variable not be expanded and replaced in inputs.
A variable that is defined as
$${...}
will be replaced with${...}
in the policy.$${...}
is not allowed in anycondition
statement, because a condition statement requires that strings always be wrapped in'...'
and so it doesn't make sense to allow it to be escaped and converted into a real string. That is already supported by just doing'${...}'
.Why is it important?
Allows users to provide values that should not be replaced in the policy.
Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files./changelog/fragments
using the changelog tool[ ] I have added an integration test or an E2E test(unit test coverage is really good)Disruptive User Impact
Adds the ability of users to escape variables.
Related issues