The core package (https://github.com/actions/toolkit/tree/master/packages/core) trims the value returned by getInput:
Is someone able to explain the thinking behind this decision? Because unless I’m missing something it means that leading and trailing spaces in input values, specifically strings, will be lost.
Yes, you are right. Github Actions getInput() function will eliminate leading and trailing spaces.
Do you need to keep the leading and trailing spaces ? Can you share an example for your usage?
Thanks. Yes, I’m clear this is how the implementation works and is currently documented. What I would like more detail on is why that decision was made.
Because it means that leading/trailing spaces in input values are lost. What if leading/trailing spaces are significant in my application? We now have no way of making them significant, because getInput removes them.
This seems to be at odds with my intuition, and at odds with environment variables implementations on Linux and macOS (where leading/trailing spaces are significant).
If the consumer of the input value wants to trim the value they can do that. I don’t see why the option for having significant leading/trailing spaces needs to be taken away from the action author by getInput trimming the space.
If your string is " hello world ", after trim(), it becomes to “hello world”. It only eliminates the beginning and trailing spaces. The space between words will not be deleted.
Can you make an example for your input string ? What’s your scenario which need the beginning and trailing spaces?
As far as I know, trim() is a common way when get input value.
Thanks, I’m quite clear on how trim() works
> If your string is " hello world ", after trim(), it becomes to “hello world”
But what if the leading and trailing space is significant? If I set an input value of " hello world ", that’s the value I expect to get back from getInput(), not “hello world”
> As far as I know, trim() is a common way when get input value.
Can you provide some examples?
Because environment variables on Linux and macOS do not trim space; the value is preserved as set, i.e. space is significant.
Thank you for your patience and explanation. I found that you have submitted an issue here https://github.com/actions/toolkit/issues/339 , please wait for the developer’s response.