-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Features/propagate goflags env #193
Changes from 6 commits
4a48392
6e1f6a1
a4c8f0a
8adafbf
80fe656
5b88091
4eaf13a
fb831a1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -273,6 +273,109 @@ func TestCmdEnginePodman(t *testing.T) { | |
} | ||
} | ||
|
||
func TestAppendEnv(t *testing.T) { | ||
type args struct { | ||
args []string | ||
env map[string]string | ||
quoteNeeded bool | ||
} | ||
tests := []struct { | ||
name string | ||
args args | ||
wantStart []string | ||
wantEnd [][2]string | ||
}{ | ||
{ | ||
name: "empty", | ||
args: args{ | ||
args: []string{}, | ||
env: map[string]string{}, | ||
quoteNeeded: true, | ||
}, | ||
wantStart: []string{}, | ||
wantEnd: [][2]string{}, | ||
}, | ||
{ | ||
name: "quote needed", | ||
args: args{ | ||
args: []string{}, | ||
env: map[string]string{"VAR": "value"}, | ||
quoteNeeded: true, | ||
}, | ||
wantStart: []string{}, | ||
wantEnd: [][2]string{{"-e", "VAR=value"}}, | ||
}, | ||
{ | ||
name: "quote not needed", | ||
args: args{ | ||
args: []string{}, | ||
env: map[string]string{"VAR": "value"}, | ||
quoteNeeded: false, | ||
}, | ||
wantStart: []string{}, | ||
wantEnd: [][2]string{{"-e", "VAR=value"}}, | ||
}, | ||
{ | ||
name: "multiple", | ||
args: args{ | ||
args: []string{}, | ||
env: map[string]string{"VAR": "value", "VAR2": "value2"}, | ||
quoteNeeded: true, | ||
}, | ||
wantStart: []string{}, | ||
wantEnd: [][2]string{{"-e", "VAR=value"}, {"-e", "VAR2=value2"}}, | ||
}, | ||
{ | ||
name: "multiple with args", | ||
args: args{ | ||
args: []string{"arg1", "arg2"}, | ||
env: map[string]string{"VAR": "value", "VAR2": "value2"}, | ||
quoteNeeded: true, | ||
}, | ||
wantStart: []string{"arg1", "arg2"}, | ||
wantEnd: [][2]string{{"-e", "VAR=value"}, {"-e", "VAR2=value2"}}, | ||
}, | ||
{ | ||
name: "multiple with args and equal sign require quoting values", | ||
args: args{ | ||
args: []string{"arg1", "arg2"}, | ||
env: map[string]string{"VAR": "value", "VAR2": "value2=2"}, | ||
quoteNeeded: true, | ||
}, | ||
wantStart: []string{"arg1", "arg2"}, | ||
wantEnd: [][2]string{{"-e", "VAR=value"}, {"-e", "VAR2=\"value2=2\""}}, | ||
}, | ||
{ | ||
name: "multiple with args and equal sign do not require quoting values", | ||
args: args{ | ||
args: []string{"arg1", "arg2"}, | ||
env: map[string]string{"VAR": "value", "VAR2": "value2=2"}, | ||
quoteNeeded: false, | ||
}, | ||
wantStart: []string{"arg1", "arg2"}, | ||
wantEnd: [][2]string{{"-e", "VAR=value"}, {"-e", "VAR2=value2=2"}}, | ||
}, | ||
} | ||
for _, tt := range tests { | ||
t.Run(tt.name, func(t *testing.T) { | ||
got := AppendEnv(tt.args.args, tt.args.env, tt.args.quoteNeeded) | ||
for i, v := range tt.wantStart { | ||
assert.Equal(t, v, got[i]) | ||
} | ||
for i := len(tt.wantStart); i < len(got); i += 2 { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. isn't I also wondered, wouldn't it make sense to simplfy to just have all the output in a single There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The issue is that you can't rely on hash map order, which is why there is two loops. One for the part that should be stable and one for the part that can vary. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh I see. But that wouldn't impact the usage of i - a single variable would better indicate that it is checking every item in the slices, even though split over two loops? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure what you exactly mean. I reused the same name ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This actually make the code a bit more complex to read. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you could increment There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not a big fan, but if that's what you had in mind, I am fine with it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The notation may not be totally awesome, but it helps to show we are actually only iterating once, despite two loops. |
||
found := false | ||
for _, v := range tt.wantEnd { | ||
if v[0] == got[i] && v[1] == got[i+1] { | ||
found = true | ||
break | ||
} | ||
} | ||
assert.Equal(t, true, found) | ||
} | ||
}) | ||
} | ||
} | ||
|
||
func TestMain(m *testing.M) { | ||
os.Unsetenv("SSH_AUTH_SOCK") | ||
os.Exit(m.Run()) | ||
|
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.
I wonder if this could have a unit test? It potentially could have a big impact on other variable appending and we have seen a few bugs recently that suggest that not all envs encode the same...
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.
Not to sure what the test could be that doesn't look like just enforcing the same code as here, since it is following docker flags interface. Maybe we should exec docker and podman in our tests for that?
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.
It could be factored out to a helper that formats the arts and demonstrates that non-trivial inputs (spaces etc) create the right format of string.
Just a little sanity checking really as a simple "x=y" seems like a potential spot for glitches in env and cmd handling.
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.
Such a tests would enforce and lock implementation details, that are not necessarily correct. That's where I have trouble imagining a test without having to spin a docker and podman command line that is not locking implementation, but actually enforce that it work.
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.
I am totally lost - why does passing an env into a printf require a docker container?
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.
If that was the case then the comment "double quote the env var when value contains the
=
char" would surely have read "double quote the env value when value contains the=
char", as the environment variable is in the KEY=VALUE format is it not?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.
I agree with Andrew. It is better to verify that the code does what we think is right than not testing it at all.
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.
I see and understand that it might be confusing. In that case, any suggestion that would be less confusing for you?
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.
I disagree on this statement. Tech debt for tests is worse than no tests. Never the less, it seems their is a consensus for having this kind of tests in, so I will oblige and add one.
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.
Test and comment change are in.