We are running postman tests from Jenkins using newman. Our postman collections and environments are exported so newman is running the collections and environments from a local file, not through a postman collection stored in their cloud
We supply the sensitive data with Jenkins such as API keys and secrets etc specifying them as a global variable from the newman command line eg --global-var “clientid=xxx”
That way no sensitive data is saved the collection file
But we are wondering when newman runs this way with a local json file for the collection and the environment and specifying the sensitive data as a global variable is this data sent to postmans servers on run time?
Just trying to understand how newman works if its just picking up the local collection and then able to send the request all internally or does it need to send all that data to postman to get it to run?
Just because we just want to be careful about where our sensitive data is stored or sent to!
Newman runs locally, so it doesn’t send data to Postman.
Our collections and environments are stored in our code repository and doesn’t go anywhere near the Postman cloud.
Not sure why you need to specify them as a global variable though.
Add the variables to the environment file and save that to your code repository alongside your collection. Both are json files.
Just make sure any confidential data is stored as current values in your environment files. Initial values sync to Postman cloud, but current values don’t.
Thanks so much for clearing up about the current values not syncing to the cloud but I am confused by this because I just added a new environment variable on one PC using postman on my corporate network and gave it initial and current values.
I then opened postman on another PC on another network with my account and both the initial and the current values were there? So they saved back to the cloud?
I was initially supplying the sensitive data as globals in Jenkins so we didnt have to have this data saved in the postman cloud but you’re right, now that I am exporting the collection and environment as json and running them locally I can keep that data in the environment file
EDIT: Ok so I see when you initially set current value, it will sync but if you update the current value the new value wont sync. Thanks a lot!
EDIT Again: I have to continue supplying global variables for sensitive data in Jenkins because when I export the environment file, it doesn’t export the current value! So I can either manually edit the JSON after export and put the values back in or just supply them globally!
Is there any other way around this? I want to keep making changes to the environment file so I dont want to have to go and keep adding the values back in everytime I export it!
This would also be the case if running the collection using the version stored in the postman cloud since the current value is not synced I would always have to supply the globals again for the sensitive data
I just had to check that. You are correct in saying that the current values do not get exported.
This is probably because those values shouldn’t really be stored in your code repository or Postman cloud.
You can send environment variables through the command line, the same as global variables.
GitHub - postmanlabs/newman: Newman is a command-line collection runner for Postman
The way this works for us is that these “secrets” are stored in a key vault.
We retrieve those settings as one of the first steps in the pipeline before including them in the Newman command line part of the pipeline.
We use Azure Pipelines and Azure Keyvault, so this is fairly seamless for us. It might be a bit more complex if you are using Jenkins and a third party application for storing confidential data.
Thanks a lot! We are not using a pipeline to run the test from Jenkins as this is not a CI build, we just want to run one off tests on the APIs so its just being run as freestyle project
I found you can setup to put the secrets in as secret text credentials in Jenkins and then in the build get them and set them as environment variables at run time so this solution is working well for us now. Thanks for all your help!