Skip to content
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

Found another cornercase #224

Merged
merged 5 commits into from
May 31, 2017
Merged

Conversation

jocgir
Copy link
Contributor

@jocgir jocgir commented May 25, 2017

There was a bug in certain circumstance whit processSingleInterpolationInString.

The regex can consider multiple interpolations as only one. The main problem is that INTERPOLATION_SYNTAX_REGEX is too general. I did not change it to avoid undesired side effects. But I added a test in processSingleInterpolationInString to ensure that there is only one match between the quotes.

I also added a test that catch the misbehaviour.

Sorry for the inconvenience.

…onInString.

The regex can consider multiple interpolation as only one.
Copy link
Member

@brikis98 brikis98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good find and test case.

Rather than adding that special-case check, I wonder if the right fix isn't to tweak INTERPOLATION_SYNTAX_REGEX. Instead of:

var INTERPOLATION_SYNTAX_REGEX = regexp.MustCompile(`\$\{.*?\}`)

Try:

var INTERPOLATION_SYNTAX_REGEX = regexp.MustCompile(`\$\{[^\}]*?\}`)

The change is that within the body of the ${...}, we capture everything other than a closing curly brace (}). I'd be curious of that passes all the tests without the extra FindAllString check.

@jocgir
Copy link
Contributor Author

jocgir commented May 25, 2017

It could work. I thought about that, but the problem with that kind of exclusion in regex is that it may have some undesired effect. Like that:

key = "${get_env("SOME_VAR", "SOME{VALUE}")}:

Which is doubtful, but perfectly valid.

@brikis98
Copy link
Member

Ah, good point. Do we have a test case for that?

@jocgir
Copy link
Contributor Author

jocgir commented May 25, 2017

Not yet.

I am trying something on regex101 to address this point

https://regex101.com/r/MVuA1t/1

I must say that in our forked terragrunt version, we made several «enhancements» that are not ready to be submitted as PR. One of them is direct support for ${var.whatever} in terragrunt config. It would be nice if we can have a talk regarding those.

@brikis98
Copy link
Member

I am trying something on regex101 to address this point https://regex101.com/r/MVuA1t/1

Heh, nice. That said, there are diminishing returns here. A small tweak to the regex to avoid extra if-statements is good, but if the fix requires a huge, hard-to-understand regex, then an if-statement is probably easier to maintain.

One of them is direct support for ${var.whatever} in terragrunt config. It would be nice if we can have a talk regarding those.

Nice. We have a couple relevant discussions going on around this topic:

#132
#147 (comment)

@brikis98
Copy link
Member

@jocgir Let me know if you found a reasonable regex to fix this. If not, happy to merge the if-statement once we add the test case mentioned above.

@jocgir
Copy link
Contributor Author

jocgir commented May 29, 2017

Yes, I think it would be preferabable to improve the regex (bug segmenting it in smaller, more readable parts).

…e but error prone)

Add a general error condition to handle non compliant interpolation syntax
Removed the if statement in processSingleInterpolationInString which become useless
Adapted the test functions

Added a function to list terraform command that accept -input as a parameter.
Add the documentation relative to get_terraform_commands_that_need_input
@brikis98
Copy link
Member

New regex looks promising! That said, it seems to still do a greedy capture, so is the reason that it works because you are now matching on word characters (\w) so that } will no longer match? Does it work correctly with the test case you mentioned earlier?

key = "${get_env("SOME_VAR", "SOME{VALUE}")}:

Had to fix HELPER_FUNCTION_SYNTAX_REGEX to be as tolerant as the generic INTERPOLATION_SYNTAX_REGEX regarding space
Removed useless parenthesis in INTERPOLATION_SYNTAX_REGEX
@jocgir
Copy link
Contributor Author

jocgir commented May 31, 2017

Hi, I just add a test to ensure it.

The \w+ just ensure that we got some_function in ${ some_function() }. We tolerate spaces around it, but not between the function name and the opening parenthesis. Just add tests for that too.

The tricky part is more in the parameters. There are still possible corner cases. Regex will never replace a real lexer/parser.

@brikis98
Copy link
Member

Great, thanks! Merging now.

@brikis98 brikis98 merged commit d3e0b80 into gruntwork-io:master May 31, 2017
@brikis98
Copy link
Member

@jocgir jocgir deleted the bugs/interpolation branch December 9, 2017 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants