-
Notifications
You must be signed in to change notification settings - Fork 211
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
Switch from StringSlice to StringArray #1931
Switch from StringSlice to StringArray #1931
Conversation
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
…r into parameter-space-error Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
workshop/hello-llama/porter.yaml
Outdated
@@ -17,18 +17,18 @@ install: | |||
command: ./helpers.sh | |||
arguments: | |||
- install | |||
- "{{ bundle.parameters.name }}" | |||
- "'{{ bundle.parameters.name }}'" |
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.
@carolynvs
We investigated this further and concluded it has to do with how the string is escaped in YAML. This probably requires an update to documentation but additionally requires code changes to existing bundles.
For the scope of this issue, would a change of documentation and a code change to the llama bundle be sufficient or do you see an alternative route?
Our proposal is to extend this documentation to include a note regarding how to handle parameters that include a space. We are unsure about the functionality behind the porter parameters generate
command and whether an update here is required.
Lastly, what we see as being out of scope is updating all the other places where YAML variables could include space and therefore could face a similar problem.
Would you agree?
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.
Hmm, I wasn't expecting the wrapping quotes to matter here, since we are parsing this and converting it into a an array of arguments in Go, e.g. ["./helpers.sh", "install", "my parameter"]. I would have expected calling a bash script in Go and passing an argument with a space to work, without the quotes. If you can look into that more, that would be great, otherwise I'll try to when I have time.
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.
From our investigation, we see that the strings get passed separately in the bash script, for example when we passed $1, $2, and so on in the /helpers.sh
that was as many words as we could get. We also tried $@ which we did not think was very optimal because this would catch all arguments even when not unique to the command. It looks like the values get read in the YAML file in the same manner.
I have had a couple of other engagements of recent and will investigate this further. In the meantime, if you get a chance to look at this and give me more pointers, that will be great. We came across https://github.com/getporter/porter/blob/release/v1/pkg/exec/builder/execute.go#L102, especially the splitCommand(args)
line, we will look at this next.
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.
We looked further into the splitCommand(args) function which was added in this commit. This does look like a possible culprit but not something we will like to change. We are potentially missing some context. Is there a chance that you @carolynvs could give us some context? Thanks in advance!
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.
Adding a note here, that I spotted that the escaping in the porter.yaml
was being done in these example bundles for flags, still not sure if they are handled differently somehow
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.
@sleepypioneer @Simpcyclassy I just realized that I completely messed up and linked to the StringArray cobra fix on the wrong pull request! I'm so sorry!
Both (parsing the comma and handling whitespace) were things that needed to be fixed, but I messed up and commented on the wrong pull request. I really didn't mean to derail you.
It sounds like you had a fix working for the space problem too? I think you were on the right track with splitCommand
. You really are close, I just accidentally threw at you a second (unreleated) bug on this pull request.
You can either fix both on this PR, or just skip the one failing test (tests/integration/install_test.go) and we can merge what you have here (which does fix the comma bug), then fix the parameter space bug in a second pull request. Whatever works easier 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.
Oh good to know, I didn't catch that there was a second bug for commas. We can look again at the splitCommand
function, we stopped looking there, after seeing about the cobra method misuse 🙈 Thanks for your patience, we are super excited to be contributing. We only meet once a week so it takes us a little time but as you said we are really close! Thanks for writing and letting us know!!
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.
@carolynvs this is the issue for the comma #1000 I will write there that this PR will add the fix.
I am not too sure how we can best change the behavior, from reading the code for splitCommand
, it is working as intended. We either need to wrap our param in extra quotes or we have to skip this processing for parameters but I am concerned that is undoing the reason this was implemented in the first place?
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.
Adding a little extra context.
If we leave the splitCommand(args)
in this is the output we see for first a param with quotes around it and secondly a param without quotes:
greenmachine@pop-os:/tmp/hello-world$ porter install --param name="demo time" --force
executing install action from porter-hello (installation: /porter-hello)
Install Hello World
Hello demo
execution completed successfully!
greenmachine@pop-os:/tmp/hello-world$ porter install --param name=demo time --force
executing install action from porter-hello (installation: /time)
Install Hello World
Hello demo
execution completed successfully!
Now the same with the call to splitCommand
removed:
greenmachine@pop-os:/tmp/hello-world$ porter install --param name="demo time" --force
executing install action from porter-hello (installation: /porter-hello)
Install Hello World
Hello demo time
execution completed successfully!
greenmachine@pop-os:/tmp/hello-world$ porter install --param name=demo time --force
executing install action from porter-hello (installation: /time)
Install Hello World
Hello demo
execution completed successfully!
We see that removing the splitCommand
call makes things behave as expected, but I am still unsure if there is an edge case we miss that makes it unwise to remove this. We could move the call up and run it only for flags (I haven't dug into how flags use this or are expected to behave) It seems at least to me that what this command was trying to solve is no longer an issue for params.
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 also thinking that in this case arguments != parameters, so we may want to only have an effect on parameters that are passed through as other arguments may still require this behavior from splitCommand
looking to see where we could do that.
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
5b2c955
to
132d348
Compare
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
@Simpcyclassy our test is failing here with the same error we saw on my computer:
You can see it here: https://dev.azure.com/getporter/porter/_build/results?buildId=3568&view=logs&j=c892508d-390a-5765-0ad0-b341c7fd0dd4&t=99b6391b-efca-5f28-e88f-b44afecfc894&l=10900 See my comment below regarding this 👇 |
So I got curious after reading the checklist in the PR I therefore checked the difference between our tests porter.yaml and another tests porter.yaml If you add the |
Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com>
p.AddTestBundleDir("testdata/bundles/bundle-with-string-params", false) | ||
|
||
installOpts := porter.NewInstallOptions() | ||
installOpts.Params = []string{"name=Demo Time"} |
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.
@Simpcyclassy try this, the problem I believe is that our test doesn't have quotes around the parameter. Rereading the issue this is expected #1862
As this should be the given command: $porter install -r getporter/hello-llama:v0.1.1 --param name="demo time"
At least for me locally this passes the tests 🎉 and from reading this again as I understand this is the intended behavior. Using single and double quotes catches both this behavior but also when no quotes were passed so that is incorrect as that would catch potentially other flags passed to the command.
|
||
output := p.TestConfig.TestContext.GetOutput() | ||
require.Contains(t, output, "Hello, Demo Time", "expected action output to contain provided file contents") | ||
} |
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.
@Simpcyclassy We should add a test after this one for checking the second bug 🐞 ie TestInstall_stringParamWithCommas
we can essentially use the same bundle and copy most of the test but change the param name to testing 1, 2, 3
instead of demo time
.
* Run mage build to generate the cli command documentation to include the recent changes * Skip the failing test that was added. This PR has enough to fix the comma parsing, and a follow-up will fix this failing test for when a parameter has a space in it. Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
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.
Thank you for the fix! Someone needed the fix on our stable (main) branch, so I'm helping to get it merged today and backported to v0.38).
I have added a commit to your PR so that I can merge what we have working now (The fix for StringSliceVar).
- Ran
mage build
so that the generated cli documenation was updated with your fix - Skipped the failing test case for parameters with spaces. We can uncomment it when fixed.
Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
* test for parameters with space Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * add contributor Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * handle bundle parameter escape Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * update parameters documentation Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * Merge branch 'release/v1' into parameter-space-error Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * array to slice paramenter Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * define params as array var Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * add schema version to yaml file Signed-off-by: Simpcyclassy <chioma.onyekpere@gmail.com> * Help get PR merged * Run mage build to generate the cli command documentation to include the recent changes * Skip the failing test that was added. This PR has enough to fix the comma parsing, and a follow-up will fix this failing test for when a parameter has a space in it. Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com> * Fix merge conflicts with release/v1 Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com> Co-authored-by: Carolyn Van Slyck <me@carolynvanslyck.com> Signed-off-by: Chioma Onyekpere <chioma.onyekpere@gmail.com>
Backport Switch from StringSlice to StringArray (#1931)
Congrats @Simpcyclassy on your first contribution 🎉 👏👏👏 Thank you @carolynvs for helping get this merged 💖 we had to take a small break due to personal commitments but we are back now and starting again to fix the parameter with a space issue 😄 |
What does this change
This change will allow for parameters containing a space to be parsed in their entirety.
What issue does it fix
Closes #1000
Notes for the reviewer
It was observed that the wrong method was being used from the
cobra
library, which resulted in parameters with space being split. We switched to using the array method and we added a test to confirm this function acts as expected.Put any questions or notes for the reviewer here.
Checklist
Reviewer Checklist