I'm currently investigating if we could run newman as part of our spring boot (java) integration tests. The idea is to use newman's docker image and start it with spotify's docker-client library directly from the JUnit test.
The issue now is that certain environment variables need to be set dynamically when starting newman like the url or the OAuth access token that should be used for the tests. The url needs to be set because the embedded tomcat starts up with a random port and the OAuth2 access token is generated randomly of course as well.
I could try to put these variables into the environment file but that means that I need to know it's format which I'd like to treat as "postman internals".
I would like to be able to pass environment vars (that have the highest precedence) on the command line, e.g. like:
newman run -e my.postman_environment.json -i accessToken=abc123 -i myServiceUrl=http://localhost:54321 my.postman_collection.json
You need to put them as environment files. The format is not Postman Internal. It is a user-facing format outlined in postman-collection repository and available as JSON schema and node module as well.
One suggestion is that you can use globals json source to store these values and environment.json could remain static.
Closing. We can continue discussion though. :-)
Dealing with the environment files in Java is tedious, esp. when you want to change an existing one or if you want to use one via the cloud API - which means downloading and modifying it.
If there's no java API to do that you're in charge to keep everything up to date when postman is evolving.
Again - I'd see the additional command line parameters as a huge benefit surely also for other use cases.
CI tools typically provide variables that can be customised when needed. Accepting command line vars will let such vars be used with newman. Updating json files is typically a code change and is not the best way to handle URLs, credentials that tend to change often.
I totally agree with both @ractive and @msadasivam, credentials should not be hardcoded in a json file // git repo.
This feature would be such a great improvement from my (and my company's) point of view.
I agree - would love to see this feature added
Just finding this thread now and I also agree that support for this would be huge as I am facing similar issues where making a code change does not make sense for something that could change on every run. @shamasis Can we have this reopened and added as a feature request?
Yes. I think I am tracking this in another issue. I think we've found a way for this - by introducing a new feature to pass in data and get result via stdin and stdout respectively. It's hypothetical still. Either that or command line arguments to override globals.
PRs welcome for the latter too.
Awesome. Thanks. I didn't see it on Trello so I wanted to put my 2 cents in on this.
@shamasis, is there any update for the above query that is related to passing the environment variable or login token through the command line. please do let us know about this
Most helpful comment
CI tools typically provide variables that can be customised when needed. Accepting command line vars will let such vars be used with newman. Updating json files is typically a code change and is not the best way to handle URLs, credentials that tend to change often.