Support Alternate Environments Format

[pfunk1978]

As a CICD user I wish to pull my environments file from the following url and use it as the environments variables for conversion
https://api.getpostman.com/environment/{UUID}

Issue:

Environments file retrieved from the postman api differs from the environments file from a postman export process. The file retrieved from the API call has the following structure

{"environment":{"id":"redacted","name":"10.0.5.49-6.3.2.x","owner":"18142191","createdAt":"2022-08-03T16:16:01.000Z","updatedAt":"2022-08-03T16:43:57.000Z","values":[{"key":"host","value":"10.0.5.49","enabled":true},{"key":"port","value":"8081","enabled":true},{"key":"v7","value":"v7","enabled":true},{"key":"v6","value":"v6","enabled":true},{"key":"jwtIssuer","value":"redacted","enabled":true},{"key":"hmacKey","value":"redacted","enabled":true},{"key":"testUser","value":"testUser","enabled":true}],"isPublic":false}}

While the file from a regular export process has the following structure

{"id":"redacted","name":"10.0.5.49-6.3.2.x","values":[{"key":"host","value":"10.0.5.49","enabled":true},{"key":"port","value":"8081","enabled":true},{"key":"v7","value":"v7","enabled":true},{"key":"v6","value":"v6","enabled":true},{"key":"jwtIssuer","value":"redacted","enabled":true},{"key":"hmacKey","value":"redacted","enabled":true},{"key":"testUser","value":"testUser","enabled":true}]}

Currently I'm getting a environment.values is not iterable error

[thim81]

Hi @pfunk1978

The feature request seems like a very logical flow.

A couple of questions:

• would you have the CI/CD download the file and next like to pass along the env file using a new parameter?
• making the cli download the file via the api would also be a valuable extension, although that would require more work since it would introduce also api credentials and implementation of the postman api. Would this be what you would expect? Or would be starting with the 1st request be already a good step forward?

[pfunk1978]

Hola @thim81,

I should also point out that the collections endpoint for postman API also returns an unusable json struct, which I didn't realize when I first wrote the ticket.

Currently I'm running curl as such and piping through jq to get the proper structure:

                sh "curl -s ${headers} https://api.getpostman.com/collections/${params.testingCollectionId} | jq '.collection' > tests/col.json"
                sh "curl -s ${headers} https://api.getpostman.com/environments/${params.environmentId} | jq '.environment' > tests/env.json" 

I have admin over my CI so I can install jq, but not everyone has that luxury. Maybe it would be better to be able to parse the above structs natively. IMHO adding in postman connectivity seems like bloat to me.

[thim81]

Hola @pfunk1978

Thanks for coming back with your input and based on it, it seems that feature can be scoped to properly parsing the Postman env file in a native manner.

As soon as I have some time, I'll review the API response to see how we can transform the Env response or support it natively.

Adding Postman API does not bring much added value, since the security and targeting which env to download would only make it more complicated and an additional hurdle.

[thim81]

Hola @pfunk1978 The PR is in the making.

I have made simple detection that will transform API environment & collection structure in a regular structure, by simply removing the wrapping element.

[thim81]

The PR has landed and the support for Postman API collection & environment files will be part of the upcoming postman-to-k6 release.

[thim81]

Closing the issue, since the latest postman-to-k6 version (1.8.5) contains this enhancement.