Allow the specification of collection variables / local variables via the command line

[vdespa]

Allow the specification of collection variables via the command line, just like it currently works for the environment and global variables.

--collection-var "foo=bar"

--local-var "foo=bar"

In this way, more variable scopes could be controlled or overridden using the CLI.

[demyan112rv]

It would be very useful to use collection variables in Newman.

[demyan112rv]

After update newman to version 4.6.0 collection variables are works!!!

[vdespa]

I haven't seen anything documented. What works and which params did you use @demyan112rv ?

[demyan112rv]

@vdespa sorry for the inaccuracy. I meant that collection variables work if you add them through a Postman to the collection. In previous versions it not worked for me.

[vdespa]

Got it. Thanks for the clarification, @demyan112rv

[shamasis]

The more I see the need to override variables ... started with none, then we added globals, then environment and now there’s a need for collection variable overrides. Let’s take a deeper look to see product-wise if we are missing something that we need to build in a wholistic way.

So, what are the use cases or jobs that we want to do here where overdriving collection variables appear to be a solution?

—

One interesting thought is that this may be showing us the need to expose “session” as a first class citizen in newman as well. Postman has this in form of initial value / current value of variables ... same may need to be exposed for all variables in Newman.

[ziazon]

A use case that I've seen the need for newman runs to be able to modify (via session maybe?) variables, is where requests are chained. Say CRUD operations, we create a record and set the ID as a variable, then get the record by the ID, update it, and then delete it, each step by the ID that was originally created. The only way around this right now it seems is to use pm.sendRequest for all the following requests and the initial request just be the creation one. But this is not ideal really. We should be able to run newman in the same way we use Runner in the desktop app.

[adrijshikhar]

@shamasis i would like to work on this feature, can you please assign it to me? Thanks.

[someshkoli]

This issue is somewhat similar to what i explained in this issue https://github.com/postmanlabs/newman/issues/2275#issuecomment-599739118 . I would like to work on this feature. If this feature is still to be implemented i request you to assign me for this.

[shamasis]

A use case that I've seen the need for newman runs to be able to modify (via session maybe?) variables, is where requests are chained. Say CRUD operations, we create a record and set the ID as a variable, then get the record by the ID, update it, and then delete it, each step by the ID that was originally created. The only way around this right now it seems is to use pm.sendRequest for all the following requests and the initial request just be the creation one. But this is not ideal really. We should be able to run newman in the same way we use Runner in the desktop app.

Why wouldn’t simply using the variable ID across all requests and setting its value using scripts work? I’m sure I’m missing something in your example. Maybe elaborate a bit more / provide sample collection?

[shamasis]

This issue is somewhat similar to what i explained in this issue https://github.com/postmanlabs/newman/issues/2275#issuecomment-599739118 . I would like to work on this feature. If this feature is still to be implemented i request you to assign me for this.

I would love to read up on proposal of sessions in CLI first before moving ahead with this feature. Can’t start unless we all agree on what we need to build. 😊 Maybe refer the Postman’s session feature in variables and then correlate to that?

[ziazon]

A use case that I've seen the need for newman runs to be able to modify (via session maybe?) variables, is where requests are chained. Say CRUD operations, we create a record and set the ID as a variable, then get the record by the ID, update it, and then delete it, each step by the ID that was originally created. The only way around this right now it seems is to use pm.sendRequest for all the following requests and the initial request just be the creation one. But this is not ideal really. We should be able to run newman in the same way we use Runner in the desktop app.

Why wouldn’t simply using the variable ID across all requests and setting its value using scripts work? I’m sure I’m missing something in your example. Maybe elaborate a bit more / provide sample collection?

Yea this doesn't work with newman because variable changes via the script section (pre-req and script) aren't persisted between requests.

[shamasis]

A use case that I've seen the need for newman runs to be able to modify (via session maybe?) variables, is where requests are chained. Say CRUD operations, we create a record and set the ID as a variable, then get the record by the ID, update it, and then delete it, each step by the ID that was originally created. The only way around this right now it seems is to use pm.sendRequest for all the following requests and the initial request just be the creation one. But this is not ideal really. We should be able to run newman in the same way we use Runner in the desktop app.

Why wouldn’t simply using the variable ID across all requests and setting its value using scripts work? I’m sure I’m missing something in your example. Maybe elaborate a bit more / provide sample collection?

Yea this doesn't work with newman because variable changes via the script section (pre-req and script) aren't persisted between requests.

Wow. Can you double check? ... that’s core feature of environment variables and same code run that in app and newman. If this were a bug, by now half the world would have been screaming!!! 🤪

1. Create a collection
2. Add two requests calling, say... httpbin.com/anything/{{myvar}}
3. In first requests pre-script write pm.environment.set to set a value of myvar.
4. Run the collection by exporting and passing to newman.

You should see both request send out with the value of myvar that you’ve set in first request’s script.

Maybe I’m missing something else?

[vdespa]

@shamasis

So, what are the use cases or jobs that we want to do here where overdriving collection variables appear to be a solution?

I am looking at this from a CI/CD perspective. I don't want to store sensitive credentials inside collections or environments.

So while developing in Postman, I have something like this:

Each user can safely store the API key while the collection/environment does not have it. Now comes the problem with CI/CD. How to override apiKey with a valid variable. Last time I checked there was no way decent way to do this.

I like the idea of session variables.

[ShahOdin]

One interesting thought is that this may be showing us the need to expose “session” as a first class citizen in newman as well. Postman has this in form of initial value / current value of variables ... same may need to be exposed for all variables in Newman.

To add to this, I would like to be able to pass collection variables to a collection as a but also be able to export the env vars. as far as I can see, I can't do either.

[vinaybu]

One usecase where collection variable comes in handy:

URL: http://localhost:8080/transaction/v1/details I store the entire url in variables, so i needn't change the collection if the url changes.

URL as variables: {{endpoint}}/{{context}}/{{resource}} endpoint = https://localhost:8080 => this can be stored in envrionment variable context =/transaction => this needs to be stored in collection variable. Each collection will have different value resource = /v1/details => this too needs to be collection variable.

[universalhandle]

I don't understand why one would want to allow specification of a value via the GUI only.

My use case:

• I have three environments: one for each deployment stage. Those environments include variables hostname, username, and password.
• My tests make requests to endpoints like https://{hostname}/{{id}}/endpoint.xml.
• id is stored in a collection-level variable. I generally avoid the global scope to avoid collisions on common names like id and to avoid polluting the global namespace with variables that are of interest to one collection only. (The Postman workspace is shared across the organization for various projects.)
• I also use the collection scope for temporary variables. For example, I've got a pre-request script which gets the results from another endpoint then stashes the result in a variable. The test for the request proper does a pm.collectionVariables.get so it can compare responses between the two endpoints. (Obviously, there's no need to specify these via CLI argument.)

Since this feature request does not appear to have much traction, I've taken the following approach to meet both the needs of Postman users who want to click "Send" and wait for a response, and newman users who are more interested in batching, automation, etc.:

• The collection-level id variable remains. Postman users adjust values as needed.
• The pre-request script is modified such that it begins with const id = pm.iterationData.get('id') || pm.collectionVariables.get('id');.
• newman users do newman run collection.json -e env.json -d iteration-data.csv.
• iteration-data.csv contains a list of IDs.

It's added a small bit of complexity to the pre-script/test, and I'm still confused as to why collection variables have second-class status, but it works.

[vdespa]

@universalhandle Thanks for sharing your use case.

I don't think you need the extra code in the pre-request script since data variables will override any existing collection variables. Correct me if I am wrong.

[universalhandle]

@vdespa, yes and no. Collection vars were overridden in the request but not in the pre-script, where you are required to specify the scope of the variable (e.g., pm.iterationData vs pm.collectionVariables. Without the added logic, the script would use the last saved collection variable value in the pre-script, at the least the way I'd written it: const id = pm.collectionVariables.get('id');. I'm pretty sure the same is true in test scripts, though I was primarily interested in pre-scripts for my use case.

Prior to my code change, my requests looked something like this:

• https://example.org/{{collectionVarId}}/other-endpoint.xml (from the pre-script)
• https://example.org/{{iterationVarId}}/endpoint.xml (from the request proper)

[vdespa]

Got it, @universalhandle

Have you tried using pm.variables.get() which is supposed to fetch a variable according to the current scope?

[universalhandle]

Ah, I forgot about pm.variables! I'll give it a spin. Thanks for the tip.

[universalhandle]

@vdespa: pm.variables.get() behaves as you described. I was able to drop the || logic from my scripts. Thanks again.