gabbi yaml does't support passing string "number" which defined in bash environment

[taget]

pip freeze | grep gab gabbi==1.46.0

1. environment variable (venv) [root@VM_62_220_tlinux /data/eli/vs_tests]# cat source.rc | grep OWNER export OWNER='251006071'

2. yaml file (venv) [root@VM_62_220_tlinux /data/eli/vs_tests]# cat create_instance.yaml | grep OWNER owner: "$ENVIRON['OWNER']"

3. but when I run this yaml with gabbit I got this "owner": 251006071,

expect "owner": "251006071",

================================

how I run gabbi:

[root@VM_62_220_tlinux /data/eli/vs_tests]# cat create_instance.yaml | grep OWN owner: "$ENVIRON['OWNER']"

ZONE_ID=100002 USER_ID='280078820' OWNER='251006071' [other environment] gabbi-run http://10.104.62.34/ < create_instance.yaml

got result: "owner": 251006071,

expect: "owner": "251006071",

[cdent]

The reason this is happening is because of the code in _environ_replace: https://github.com/cdent/gabbi/blob/master/gabbi/case.py#L217-L241

which casts things that look like numbers to numbers after the the yaml and environ processing.

I'm doing some experiments to see if there's a way to work around this and I'll post back.

[cdent]

e3fb2cfa398e5591ba is the commit where this functionality was done.

The history was that someone had the opposite problem as you: anything that is in an environment variable is always a string and there was no clear way to make a number be a number.

The challenge is that the replace functionality is after the yaml has been processed, this is different from how things like ansible work, which does pre-processing of the template.

Fixing this is going to take some thought, I don't have any immediate ideas. Basically there needs to be a way to work around the casting.

I'll keep thinking about it. If you have any ideas, please respond with them.

[cdent]

After thinking about it more, there's no easy way to address this without changing gabbi, and because of the existing precedent, it's hard to change things without break existing tests that are out there in the world.

However, one option for a potential fix is to put type "hints" in the name of the environment variable and then interpret them. Something like ['FOOBARint'] (but better than that).

Needs further thought. @taget would that potentially work for you?

[taget]

@cdent thanks for taking time to looking at this issue, I am ok that we can use something like 'hint' to tell gabbi that this environment variable are number or string like, just want to be sure that the naming should not conflict with the existed one.

of cause, we don't want to break the existing test case, that will be bad practice for other users.

[cdent]

I won't be able to work on an implementation of this until July. @taget, if this is something you might be able to work on, please give it a go. Otherwise I'll look more closely when July comes around.

[taget]

@cdent hi Chris, are you still working on this ?

[cdent]

Sorry, it's still on my radar, but July and now much of August has passed by and I've not yet made any progress. The challenge is coming up with a generic way to do it that doesn't break existing tests. I do hope to get to it soon.

[cdent]

Please have a look at #275 and let me know if you think it might be workable for your needs.