You’re correct that the Postman CLI doesn’t natively support fetching different versions or branches of a collection. This is because collections in Postman are not maintained like a codebase in a Git repository. In Postman, when you save changes to a collection, those changes become the ‘current’ version of that collection, regardless of branch. It’s more of a single active ‘state’ system than a repository of multiple accessible versions or branches.
When you run a collection with Newman or the Postman CLI, it grabs the current saved state from Postman, which may be the latest published version. But it doesn’t inherently know or care about branches; it’s working with the current active state of your collection.
So when you run a collection using the CLI, it uses the state of the collection as it is currently saved in Postman. If you have multiple branches in your Postman collection, you have to manually switch to the branch you want to run, save the collection, and then run it.
Now, for your
develop branch workaround, I get why you’re thinking of doing that. But there might be a simpler way. What if you exported the specific version of the collection you want to test and then fed that file into Newman?
That way, you can run tests on any branch, at any time, without having to disturb the current active state of your collection in Postman. And no need to add or manage extra branches just for testing!
This method, however, means you need to manually export the collection each time you switch branches, which could be a pain depending on your workflow. I totally get it if this isn’t a perfect solution, but it might help in the interim.
As for seeing all collection run results from all sources, you could integrate Postman with a CI/CD tool like Jenkins or Travis CI. Then, you can store and manage your test results more effectively. Also, Newman and the Postman CLI offers several ways to output test results, such as JSON, XML, HTML, etc. This can give you more control over how you store and view your results.