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
Revert environment regexp in opts #16608
Conversation
|
||
if !EnvironmentVariableRegexp.MatchString(variable) { | ||
return []string{}, ErrBadEnvVariable{fmt.Sprintf("variable '%s' is not a valid environment variable", variable)} | ||
// trim the front of a variable, but nothing else |
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.
Perhaps you should add some of the discussion in this PR (and the linked issue) in a comment (and in the commit message) to explain why we're not validating that the characters are valid for environment vars. (also to prevent someone to re-introduce the regex in future)
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.
@thaJeztah true 😝
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.
and done :)
c7cd98a
to
1ca5514
Compare
// trim the front of a variable, but nothing else | ||
variable := strings.TrimLeft(data[0], whiteSpaces) | ||
if strings.ContainsAny(variable, whiteSpaces) { | ||
return []string{}, ErrBadEnvVariable{fmt.Sprintf("variable '%s' has white spaces", variable)} |
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.
why trim whitespace? It's technically allowed to have an env var with leading whitespace.
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.
@phemmer it's how it was done before the regexp so I reverted to it. But yeah.. and in ValidateEnv we do not trim leading space so.. there is something to do.. (probably removing this trim)
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.
let's leave this here. I'd rather have the previous behavior, that seemed to work as expected, than a new different behavior.
@vdemeester can we add a couple new regression tests to |
@calavera yes, will do 😉. |
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
1ca5514
to
7335544
Compare
@calavera done 😉 |
LGTM |
1 similar comment
LGTM |
Revert environment regexp in opts
Remove the environment regexp introduced in #13694 as it makes some application not working anymore.
As said in #16585
Even if I was liking this, as @tianon said, docker should be tolerant on the environment passed as is — separation of concern, it's up to the application to handle this or not 😅.
The only question I have on that one is the fact that
ParseEnvFile
behave differently fromValidateEnv
as it checks from white spaces where the other don't. What should we do there ?Fixes #16585
Signed-off-by: Vincent Demeester vincent@sbr.pm