You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By reading this --variable option on cli always supercedes everything then comes the variables-file option then the environment variables and last but not least the Options section in the file.
However i'd think that's kind of strange
A better order (in my opinion) would be:
--variable option
environment variables
--variable-file option
options section in specific file
This ensures system variables are prefered over local files. In my instance i'm sharing the .env files through git where the localhost.env contains a different value for every user. I can't specify it in the variable-file since it differs, so i'd add it to my environment
what's your take on this?
The text was updated successfully, but these errors were encountered:
Regarding options, the current behaviour is that options defined on a specific request take precedence over options defined on command line. For instance, given this file:
GET https://foo.com
GET https://bar.com
[Options]
insecure: false
GET https://baz.com
[Options]
insecure: true
With this command $ hurl --insecure test.hurl, will run:
Personnaly, I would really dislike if, given this file:
GET https://foo.com
HTTP 200
GET https://bar.com
[Options]
insecure: false
GET https://baz.com
[Options]
insecure: true
Hurl could execute a insecure request on bar.com (in this model, the source code overrides the model, options on requests are more "specific").
Variables work like options. Given this Hurl file:
GET https://foo.com
[Options]
variable token=foo
With this command $ hurl --variable token=bar, the variable value resolved is "foo". Like any other options, variable defined on requests override variable defined in command line. Variable can also be obtain from capture:
GET https://foo.com
GET https://bar.com
HTTP 200
[Captures]
token: body
In this case, token variable is resolved dynamically when requesting <bar.com> Once again, I would find it hard to understand that running this file with $ hurl --variable token=foo will not change the value of token variable on the second HTTP response.
Regarding variable vs variable-file, we have not specified exactly in which order we read variables, it depedent on the actual code!
We have a couple of ways to specify variables, however i'm not sure what the order is.
By reading this
--variable option
on cli always supercedes everything then comes the variables-file option then the environment variables and last but not least the Options section in the file.However i'd think that's kind of strange
A better order (in my opinion) would be:
This ensures system variables are prefered over local files. In my instance i'm sharing the
.env
files through git where thelocalhost.env
contains a different value for every user. I can't specify it in the variable-file since it differs, so i'd add it to my environmentwhat's your take on this?
The text was updated successfully, but these errors were encountered: