I’m looking to establish an Azure Git repository as the single source of truth for my API’s Postman collections, and I have a few questions about integrating Postman with this workflow.
I’ve successfully connected my Postman collection to a local Git repository. However, I’ve noticed that the Postman application primarily shows push and commit buttons for Postman Cloud, rather than direct Git operations like pushing to a remote Azure DevOps repository.
My understanding is that Postman has shifted towards a more ‘native Git integration’ model, implying that core Git operations like git push and git commit to the remote should be handled via the terminal or a dedicated Git client.
Could you elaborate on this workflow and confirm if this is the intended approach for managing Postman collections with an external Git repository as the source of truth?
Given that my Postman collection is stored as a directory tree of *.yaml files in the Git repository for better version control, I’m encountering an issue where Newman, the traditional Postman collection runner, seems to require a single JSON file.
Should I be considering the newer Postman CLI for running these tests directly in a pipeline from my Git-managed directory structure, or is there a recommended approach to use Newman effectively in this scenario.
Assuming the successful implementation of the previous two steps (Git as source of truth and automated testing), how can I ensure that the entire team always has access to the latest version of the API without the need to manually pull from GIT?
Is it possible to integrate this process with CLI commands (e.g., using Postman CLI) to programmatically push changes from my Azure Git repository to Postman Cloud, thereby keeping everyone’s Postman workspaces synchronized with the Git-controlled source of truth?
It’s awesome to see and hear about the changes you’re making!!
I’ll try and go through your points/questions and answer these:
There isn’t a “Git Client” in the platform so all those git operations would be done either using the built-in terminal, your favourite IDE or connecting your remote git provider MCP to Agent Mode and have that do all the heaving lifting for you.
I would recommend using the Postman CLI for everything moving forward, including running the yaml Collections.
There is a slight difference when running a Collection, you’re not pointing to a single Collection file like you do with the JSON files, you point to the directory. If you’re using an environment, you will still be pointing to the single file yaml though.
postman collection run "./postman/collections/{{projectFolder}}" --environment "./postman/environments/{{EnvironmentFile}}.yaml"
The Postman CLI has a postman workspace push command, that can be added to your workflow/pipeline file to push local collection changes to your Postman workspace. It syncs the local files with the workspace in the Postman cloud.
This is a very recent post by @gbadebo-bello that will cover many of this things and explain more about collaborating with your team using the native git feature.
Thank you for your response. It solved all my issues.
Building on our previous discussion, is it possible to establish an automated workflow where an updated openapi.json specification is automatically converted into Postman collections yaml files using Postman CLI?
Some sort of postmant import openapi.json or postman convert openapi.json?
Scenario:
developer updates openapi.json in a repository
openapi.json is converted to postman folder with yaml files
the rest of the scenario continues as if in previous question
